Pregunta de investigación

¿Cuándo utilizar MCP y cuándo integrar una API directamente?

Criterios de interoperabilidad, permisos y mantenimiento para no confundir un protocolo de herramientas con la API de negocio.

Respuesta breve

MCP encaja cuando varios clientes de IA deben descubrir y utilizar recursos o herramientas con una interfaz común. Una API directa sigue siendo preferible para integraciones estables, de alto rendimiento o con contratos de negocio que no necesitan descubrimiento por un modelo.

Contexto

MCP normaliza cómo un host de IA encuentra herramientas, recursos y prompts. No sustituye la lógica, la autorización ni los contratos de la API que hay detrás.

Añadir una capa MCP a una única llamada interna puede crear mantenimiento sin aportar interoperabilidad. Exponer una API completa como herramientas, en cambio, amplía innecesariamente la superficie de riesgo.

Ejemplo didáctico · situación inventada

La misma consulta desde dos asistentes

Un asistente interno y un cliente de escritorio necesitan consultar el estado de un expediente. La API ya comprueba qué expedientes puede ver cada usuario.

Qué decisión cambia. Una herramienta MCP puede reutilizar esa consulta entre clientes. El servidor mantiene la autorización de la API: conocer un identificador o descubrir la herramienta no concede acceso al expediente.

Qué comprobar antes de empezar

  • Número de clientes, modelos y proveedores que deben reutilizar la integración.
  • Necesidad real de descubrir herramientas o recursos en tiempo de ejecución.
  • Contrato de autenticación, audiencia del token y separación entre usuarios.
  • Volumen, latencia y semántica de reintentos de cada operación.
  • Qué campos de la API no deben quedar expuestos al modelo.

Método de trabajo

Definir el contrato de negocio

La API conserva validaciones, idempotencia y autorización aunque exista un servidor MCP.

Diseñar herramientas estrechas

Cada herramienta representa una intención concreta, no un proxy genérico a cualquier endpoint.

Separar identidades

Validamos audiencia y alcance de tokens; un token recibido no se reenvía sin control a otro recurso.

Probar dos clientes

La interoperabilidad se comprueba con clientes distintos y con errores de autorización, versión y transporte.

Señales para detener la prueba

  • Solo existe un consumidor estable y la capa adicional no reduce trabajo.
  • El servidor actúa como proxy de credenciales o acepta tokens destinados a otro recurso.
  • Las herramientas exponen operaciones genéricas que el modelo puede combinar sin límites.
  • La latencia o el volumen hacen inviable el transporte elegido.

Fuentes

Para seguir con esta decisión

Servicio de Agent Engineering: alcance y entregables

Publicado por Ordantis el .

Primera conversación

Trae el problema, los datos disponibles y la condición que no puede fallar.

Iniciar diagnóstico