MCP para agentes de IA en desarrollo de software

Gerente Comercial de ACL powered by DataArt

Un agente puede proponer una historia de usuario, explicar una función o sugerir una corrección. Para trabajar sobre un proyecto real, también necesita consultar información actualizada y, en algunos casos, actuar sobre las herramientas del equipo.

Ahí aparece MCP.

Model Context Protocol —MCP— es un protocolo abierto que estandariza cómo una aplicación de IA accede a herramientas y fuentes de información. En desarrollo de software, puede utilizarse para conectar agentes con Jira, repositorios, SonarQube o Figma, según las capacidades disponibles en cada servidor y los permisos configurados.

Para un líder de ingeniería, la decisión va más allá de habilitar una conexión. Hay que definir qué puede consultar el agente, qué puede modificar y qué evidencia necesita el equipo para aceptar el resultado.

Leer una historia en Jira y cambiar su estado son acciones distintas. Consultar código y autorizar un merge también. Esa diferencia debe quedar resuelta antes de ampliar la autonomía.

Qué es MCP

MCP establece una forma común de comunicación entre una aplicación de IA y servidores que exponen capacidades concretas. Estas pueden incluir herramientas ejecutables, recursos de información y plantillas de prompts.

En su arquitectura participan la aplicación que aloja al agente, el cliente MCP que utiliza para comunicarse y el servidor que ofrece las capacidades. Como explica la documentación oficial de MCP, el protocolo organiza ese intercambio; no determina por sí solo cómo razona el modelo ni cómo la aplicación administra el contexto.

Su utilidad empresarial está en facilitar conexiones reutilizables entre aplicaciones compatibles. Sin embargo, contar con un servidor MCP no significa que todas las funciones del sistema conectado estén disponibles ni que todas deban habilitarse.

La selección depende del caso de uso, la implementación y los controles de la organización.

Por qué los agentes necesitan herramientas

El conocimiento general del modelo no le permite saber cuál es el estado actual de una historia, qué versión de un componente utiliza el proyecto o qué hallazgos mantiene abiertos un análisis de calidad.

Las herramientas permiten consultar esos antecedentes y ejecutar operaciones sobre sistemas concretos.

Pensemos en un ejemplo ilustrativo: el equipo debe incorporar una nueva consulta al portal de clientes. Para preparar una propuesta, el agente podría necesitar leer los criterios de aceptación, revisar una pantalla aprobada e identificar los componentes existentes.

Después podría proponer cambios y consultar resultados de validación. Cada paso requiere información diferente y puede tener consecuencias distintas.

Aquí conviene separar tres elementos:

Contexto: información necesaria para entender la tarea.
Skills: instrucciones y recursos reutilizables que orientan cómo realizarla.
Herramientas conectadas mediante MCP: capacidades que la aplicación puede invocar.

Esta relación complementa lo que abordamos en contexto y Skills para agentes de IA. Un procedimiento puede indicar qué revisar; la herramienta permite obtener esa información o realizar una operación.

MCP vs. integración tradicional

MCP puede convivir con APIs, conectores y automatizaciones existentes. Un servidor MCP puede utilizar la API de un producto para atender una solicitud.

La diferencia está en ofrecer a los clientes compatibles una interfaz común para descubrir e invocar las capacidades expuestas.

Para decidir cuándo utilizarlo, conviene evaluar el trabajo que se busca resolver:

Si un agente necesita elegir entre distintas consultas según la tarea, MCP puede facilitar el acceso a esas herramientas.
Si un proceso ejecuta siempre una secuencia fija, una integración directa o un workflow existente puede ser suficiente.
Si varios clientes de IA necesitan capacidades similares, conviene evaluar un servidor MCP compartido y administrado.
Si la operación tiene alto impacto, la arquitectura debe incorporar validaciones y autorizaciones, independientemente del protocolo.

MCP tampoco elimina el mantenimiento. Alguien debe hacerse responsable del servidor, sus dependencias, los cambios en las herramientas expuestas y la compatibilidad con los sistemas de destino.

La decisión útil es qué problema de integración resuelve y qué responsabilidad operativa agrega.

Cómo funciona una conexión MCP

Desde la perspectiva del equipo, el recorrido puede entenderse en cinco pasos:

Habilitar el servidor. La organización selecciona una implementación confiable y define dónde funcionará.
Configurar el acceso. Se establece la identidad y el alcance autorizado según el mecanismo de esa conexión.
Descubrir las capacidades. El cliente obtiene las herramientas disponibles y la información necesaria para invocarlas.
Solicitar una operación. La aplicación envía la llamada, aplicando las restricciones y aprobaciones configuradas.
Revisar el resultado. La respuesta permite continuar la tarea o identificar errores y decisiones pendientes.

La aprobación humana no aparece automáticamente por utilizar MCP. Depende del cliente, del flujo y de las políticas implementadas.

Tampoco conviene interpretar una respuesta exitosa como prueba de que se cumplió el objetivo de negocio. Crear un ticket confirma que existe un registro; su contenido todavía puede necesitar revisión.

Mano robótica utilizando un computador portátil, acompañada de iconos de inteligencia artificial y control de procesos — Conectar agentes de IA con herramientas mediante MCP requiere definir permisos, límites de acción y puntos de revisión humana.

Jira: conectar al agente con el trabajo acordado

Jira permite conectar el trabajo del agente con el backlog y los acuerdos del equipo.

La documentación de Atlassian describe capacidades para buscar, crear y actualizar elementos de trabajo mediante su servidor MCP. Las operaciones respetan los permisos del usuario autenticado.

En un flujo de requisitos, una aplicación podría utilizar esas capacidades para consultar una épica y preparar una propuesta de historias. El equipo debe decidir si el agente puede guardarlas directamente o si primero debe presentar un borrador.

Para comenzar, conviene definir:

En qué proyectos puede operar.
Qué tipos de elementos puede crear o modificar.
Qué campos puede actualizar.
Qué cambios requieren revisión previa.

Una historia generada tampoco debería considerarse lista solo porque fue creada en Jira. Debe cumplir las condiciones de preparación acordadas por el equipo, como explicamos en cómo usar IA para definir requisitos de software.

Repositorios: distinguir lectura, modificación e integración

El acceso a un repositorio permite consultar implementaciones, pruebas y documentación técnica. Las operaciones disponibles dependerán del servidor elegido y de su configuración.

Para un piloto, puede ser suficiente permitir lectura de un repositorio específico. Si el caso necesita escritura, hay que precisar dónde se permiten los cambios y cómo llegarán a revisión.

En su documentación para configurar servidores MCP en repositorios, GitHub recomienda limitar las herramientas habilitadas y priorizar las de lectura. También advierte que, en ese entorno, el agente puede utilizar las herramientas autorizadas sin solicitar aprobación en cada llamada.

Esto obliga a revisar el comportamiento del cliente, además de los permisos del servidor.

Un flujo puede permitir preparar cambios en una rama y mantener protegidas la integración y la publicación. Consultar código, modificar archivos, abrir una solicitud de cambios y hacer merge deben tratarse como capacidades separadas.

SonarQube: incorporar evidencia de calidad y seguridad

SonarQube puede aportar información sobre calidad y seguridad del código al trabajo del agente.

Su servidor MCP permite recuperar información y realizar operaciones sobre SonarQube Server o SonarQube Cloud mediante sus APIs. También contempla análisis de fragmentos de código.

Una aplicación posible es consultar los hallazgos pertinentes para un cambio, proponer una corrección y revisar posteriormente el resultado del análisis.

La decisión de ingeniería está en definir qué evidencia se utilizará para aceptar esa corrección. Conviene identificar el proyecto, la rama o revisión analizada y los controles aplicables.

El agente no debería declarar que resolvió un hallazgo únicamente porque modificó el código. La comprobación debe corresponder al cambio evaluado.

Asimismo, un análisis satisfactorio de calidad no demuestra por sí solo que la funcionalidad responda a la necesidad del negocio. Las pruebas funcionales y la revisión mantienen su lugar en el flujo.

Figma: utilizar el diseño como contexto de implementación

Figma puede aportar contexto de diseño para implementar una interfaz: estructura, componentes y referencias visuales, según las herramientas disponibles y el acceso concedido.

Su documentación distingue entre las capacidades que expone el servidor MCP y el trabajo que realiza el agente con ellas. También aclara que la conexión no convierte automáticamente un diseño en código terminado.

Para el equipo, conviene definir qué archivo y qué versión del diseño se consideran referencia, cuáles son los componentes aprobados y qué aspectos necesitan revisión de diseño o desarrollo.

En el portal del ejemplo, consultar una pantalla puede ayudar a entender la distribución de la información. Las reglas sobre quién puede ver una solicitud deben provenir de los requisitos y controles de autorización.

El contexto visual y el contexto de negocio se complementan. Ambos son necesarios para evaluar la implementación.

Permisos y credenciales

Antes de habilitar una herramienta, el equipo debería poder responder cuatro preguntas: con qué identidad actúa el agente, a qué recursos accede, qué operaciones puede realizar y cómo se revoca ese acceso.

Un punto de partida es aplicar mínimo privilegio: habilitar únicamente las capacidades necesarias para el caso de uso.

En la práctica, esto implica separar lectura de escritura, restringir proyectos o repositorios y evitar cuentas con permisos amplios cuando la tarea puede resolverse con un alcance menor.

Las credenciales deben gestionarse mediante mecanismos autorizados de la aplicación y la infraestructura. No deberían incorporarse al prompt, a una Skill o a documentación que el agente pueda reproducir en su respuesta.

El mecanismo de autenticación depende de la conexión. Por ejemplo, Atlassian documenta autorización OAuth y respeto de los permisos existentes del usuario. Eso no debe generalizarse a cualquier servidor MCP.

También conviene comprobar la revocación: quién puede deshabilitar el servidor o la credencial y cómo se detiene el acceso cuando termina un proyecto o cambia una responsabilidad.

Persona trabajando en un portátil frente a tres monitores con código, acompañada de iconos de automatización y colaboración — El uso de MCP en el desarrollo de software debe integrarse al flujo del equipo, con permisos definidos y revisión humana de las acciones críticas.

Riesgos de dar herramientas a un agente

Cuando un agente puede actuar sobre sistemas, una interpretación incorrecta puede convertirse en una modificación real.

Los riesgos que conviene evaluar incluyen:

Acciones fuera de alcance: modificar más registros o archivos de los previstos.
Exposición de información: recuperar datos que después se envían a un destino no autorizado.
Instrucciones maliciosas dentro del contenido: tratar el texto de un ticket o documento como una orden para cambiar el comportamiento.
Servidores no confiables: ejecutar software o conectarse a servicios sin revisar su procedencia.
Operaciones duplicadas: repetir una escritura después de un error o una respuesta ambigua.
Acciones basadas en información antigua: continuar sobre una historia o un diseño que cambió desde su consulta.

Las recomendaciones oficiales de seguridad de MCP abordan, entre otros asuntos, el manejo incorrecto de tokens y el compromiso de servidores locales. Utilizar el protocolo requiere atender esos riesgos de implementación.

Como controles de operación, conviene delimitar herramientas, validar los parámetros sensibles, revisar cambios de alto impacto y registrar los resultados.

Los reintentos también necesitan reglas: una operación que crea o modifica información no debe repetirse a ciegas. Antes de volver a ejecutarla, puede ser necesario comprobar si el primer intento produjo un cambio.

MCP dentro de un SDLC gobernado

MCP aporta una vía de conexión. La gobernanza establece en qué condiciones se utiliza y quién responde por las decisiones.

Leonel Hernández, Deputy CTO de ACL powered by DataArt, explica cómo se distribuye esa responsabilidad en SPIREX®:

“Significa que la IA puede ejecutar, proponer y acelerar, pero las decisiones críticas siguen pasando por una persona. En Spirex, el humano valida momentos clave del recorrido, como la revisión de historias o el gate de entrega. La lógica es simple: la IA ejecuta, pero el humano decide. Eso permite mantener criterio técnico, responsabilidad y control sobre lo que avanza.”

Al conectar herramientas mediante MCP, ese criterio debe traducirse en permisos y puntos de revisión concretos. El equipo necesita distinguir qué puede consultar el agente, qué cambios puede preparar y cuáles requieren autorización antes de ejecutarse.

Con SPIREX®, ACL presenta MCP como parte de la conexión de agentes con herramientas como Jira, repositorios, Figma y SonarQube. Esa capacidad se integra con contexto, Skills y revisión humana dentro del flujo de desarrollo.

Para evaluar un caso concreto, se puede comenzar con una tarea acotada: preparar una propuesta de cambio a partir de una historia, consultar el código y el diseño relacionados y presentar los hallazgos al equipo.

Este es un flujo ilustrativo, no un caso de cliente ni una promesa de automatización completa. Cada conexión y operación debe comprobarse en el entorno donde se utilizará.

Antes de ampliar su alcance, conviene acordar:

Objetivo: qué trabajo se espera resolver.
Herramientas: cuáles necesita realmente.
Permisos: qué puede consultar y modificar.
Aprobaciones: qué decisiones requieren intervención humana.
Evidencia: cómo se relacionan la solicitud, las llamadas, los cambios y la validación.
Recuperación: qué hacer si una operación falla o produce un resultado incorrecto.

La medición debería incluir tiempo total, esfuerzo de revisión, correcciones y acciones fuera de alcance. Contar llamadas a herramientas muestra actividad; para evaluar valor hay que comprobar qué resultados aceptó el equipo y cuánto trabajo requirieron.

Esta es la conexión con un SDLC gobernado: disponer de herramientas útiles, límites claros y evidencia suficiente para decidir si el flujo puede ampliarse.

Dentro del desarrollo de software con IA, MCP tiene sentido cuando ayuda a resolver una tarea concreta y el equipo puede controlar sus consecuencias.

¿Tu equipo está evaluando cómo conectar agentes con sus herramientas de desarrollo? Conversemos sobre SPIREX® y revisemos un caso acotado, sus permisos y los criterios necesarios para medirlo antes de escalar.

Preguntas frecuentes

¿MCP reemplaza las APIs?

No. Un servidor MCP puede utilizar las APIs existentes para atender solicitudes. MCP aporta una interfaz común para que aplicaciones de IA compatibles accedan a las capacidades expuestas.

¿Conectar un servidor MCP permite al agente hacer cualquier cosa?

No. Su alcance depende de las herramientas habilitadas, la identidad utilizada, los permisos del sistema de destino y los controles de la aplicación. Es necesario revisar cada capa.

¿Cuál es la diferencia entre MCP y una Skill?

Una Skill organiza instrucciones y recursos para orientar una tarea. MCP permite comunicar la aplicación de IA con herramientas y fuentes de información. Pueden utilizarse juntos dentro de un mismo flujo.

¿Todas las acciones necesitan aprobación humana?

Depende de su impacto y de la política del equipo. Las lecturas acotadas y las modificaciones sensibles pueden requerir controles diferentes. MCP no impone automáticamente una aprobación en cada operación.

¿Por dónde conviene empezar a utilizar MCP?

Por una tarea concreta, con acceso limitado y criterios de evaluación definidos. Un piloto de lectura puede ayudar a comprobar utilidad y manejo del contexto antes de habilitar operaciones de escritura.

¿Te ha interesado este contenido? No te pierdas nuestros otros artículos

Contrata a los mejores desarrolladores de software en Latinoamérica

Accede a talento top y soluciones de TI eficientes con nuestros servicios Nearshore.

Contáctanos