Conecta un agente con un sistema de negocio solo después de definir qué datos y acciones necesita la tarea. Una API define cómo intercambian solicitudes los sistemas; MCP estandariza la conexión de aplicaciones de IA con servidores que ofrecen contexto y herramientas; los permisos deciden qué usuario o agente puede utilizar una operación. Estas decisiones se complementan, pero no son intercambiables.
Las fuentes, las instrucciones, las acciones y los sistemas respaldan una tarea acotada.
Distingue el protocolo, la conexión y el permiso
Cada capa responde a una pregunta distinta:
Desplázate horizontalmente para ver todas las columnas.
| Capa | Qué define | Qué no decide |
|---|---|---|
| API | Qué solicitud y respuesta acepta un sistema de negocio. | Si ese usuario o agente debe tener permiso para realizar la solicitud. |
| MCP | Cómo se conecta una aplicación de IA con un servidor que ofrece recursos, instrucciones o herramientas. | Si los datos o acciones del servidor están autorizados para un flujo de trabajo concreto. |
| Política del agente | Qué capacidades públicas, herramientas y límites expone actualmente un agente externo. | Si el agente puede utilizar cualquier API o servidor MCP. |
MCP puede facilitar el descubrimiento y uso de la interfaz de un servidor entre aplicaciones compatibles. El protocolo no hace cumplir por sí solo los permisos de negocio de tu organización; cada implementación debe aplicar sus propios controles de acceso y consentimiento. La documentación actual del SDK de agentes externos indica que las integraciones consultan la política pública y las capacidades negociadas del agente. No documenta un conector MCP general, así que no des por sentado que añadir un servidor MCP lo habilita en este SDK.
Una conexión es la ruta configurada entre un flujo de trabajo de agente y un sistema. Incluye a la persona responsable, una identidad, la operación expuesta y las reglas que aplica el sistema. Una consulta de solo lectura y un punto de acceso para actualizar datos pueden usar la misma API, pero tienen consecuencias distintas y deberían contar con autorizaciones separadas.
Analiza una solicitud acotada
Considera un centro de servicio que recibe esta solicitud: «Consulta el estado de inspección del activo A-104». El sistema de registro contiene una entrada de inspección marcada como completada el 25 de septiembre. La primera tarea consiste en devolver ese registro; no hace falta modificar la inspección ni programar mantenimiento. Comprueba el límite de identidad y permisos en cada paso:
- Verifica a quien hace la solicitud. Autentica a la persona mediante el inicio de sesión habitual de la aplicación; no te bases solo en una identidad enviada desde el navegador. Quien administra el centro de servicio decide qué personas pueden consultar el estado.
- Nombra la fuente y a su responsable. El sistema de mantenimiento es la fuente del estado de inspección y su responsable confirma qué operación aprobada puede leerlo.
- Identifica la identidad de conexión. Registra qué identidad de usuario o servicio hará la llamada al sistema y confirma su acceso real con quien administra ese sistema.
- Limita los permisos del sistema. Para esta solicitud, permite leer el estado de inspección de los activos autorizados. Mantén fuera de esta conexión las actualizaciones y la programación de mantenimiento, salvo aprobación independiente.
- Comprueba la capacidad del agente. En un agente externo, consulta su política pública vigente y los detalles de sus herramientas de dominio antes de mostrar una acción. Confirma la clase de efecto secundario de la operación y si requiere aprobación; el nombre de un protocolo por sí solo no concede acceso.
- Verifica el resultado y cuándo detenerse. Devuelve el estado y la fecha registrados. Remite a la persona responsable un registro faltante o contradictorio en vez de deducir el resultado.
Consulta completada (ejemplo ilustrativo)
Solicitud: Consultar el estado de inspección del activo A-104.
Identidad solicitante: Una persona del centro de servicio con sesión iniciada y autorizada por quien administra el equipo.
Identidad de conexión: Una identidad de integración aprobada y de solo lectura puede consultar el estado de inspección.
Capacidad del agente: La política vigente expone la consulta; la interfaz no muestra una acción de actualización.
Resultado de la fuente: Inspección marcada como completada el 25 de septiembre.
Acción permitida: Leer el estado; no modificar el registro.
Respuesta: «La última inspección figura como completada el 25 de septiembre».
Este ejemplo supone que la consulta de solo lectura ya está autorizada en el sistema. No implica que el SDK proporcione esta operación ni que MCP conceda acceso a los datos de mantenimiento.
Prueba los límites antes de ampliar el acceso
Prueba una solicitud permitida, otra de una persona sin acceso, una ficha faltante y un registro con fechas contradictorias. Confirma que los casos denegados o inciertos no revelen datos ajenos. Si una operación cambia un registro, identifica quién la aprueba y qué evidencia confirma que el cambio se completó.
Para entender las diferencias básicas, consulta conocimiento, habilidades, herramientas y conexiones. Revisa permisos y límites de los agentes de IA y luego la guía del SDK sobre políticas y capacidades para conocer las capacidades que un agente expone realmente.