MCP (Model Context Protocol) en Copilot Studio

Descubre qué es MCP (Model Context Protocol), cómo funciona y por qué en Copilot Studio simplifica la conexión con APIs, datos y herramientas, con más gobernanza y menos mantenimiento.

En la práctica, la mayoría de agentes fallan por lo mismo: les falta contexto “vivo” (datos actuales, documentos internos, catálogos, estados de procesos) y capacidad de acción (crear un caso, lanzar un flujo, actualizar un registro). MCP (Model Context Protocol) nace precisamente para estandarizar esa conexión entre un agente y el “mundo real”.

¿Qué es MCP?

MCP (Model Context Protocol) es un protocolo abierto para conectar aplicaciones con LLMs (clientes) con fuentes de datos y herramientas externas (servidores) de forma estandarizada. En otras palabras: define un “idioma común” para que un agente pueda descubrir qué puede leer y qué puede ejecutar fuera del modelo.

Una analogía popular lo resume muy bien: MCP es como un “USB-C” para apps de IA, porque permite enchufar capacidades (datos + acciones) de muchos sistemas de manera uniforme.

Las 3 piezas que expone un servidor MCP

Cuando conectas un agente a un servidor MCP, ese servidor puede publicar:

• Resources (recursos): “datos tipo fichero” que el agente puede leer (por ejemplo: contenido de un documento, respuesta de una API, un JSON con resultados).
• Tools (herramientas): funciones accionables que el modelo puede invocar (crear ticket, consultar stock, aprobar una solicitud…).
• Prompts: plantillas y flujos de prompts reutilizables para tareas concretas.

Cómo “habla” MCP por dentro (muy resumido)

MCP se basa en mensajes JSON-RPC 2.0, con conexiones con estado y negociación de capacidades entre cliente y servidor.

En transporte, el estándar define stdio (subproceso local) y Streamable HTTP (servidor HTTP con POST/GET y streaming opcional).

Cómo “habla” MCP por dentro (explicación extendida y técnica)

Cuando hablamos de cómo “habla” MCP (Model Context Protocol) por dentro, nos referimos a su modelo de comunicación entre un cliente (LLM / agente) y un servidor MCP que expone recursos y herramientas. MCP no es solo un formato JSON: es un protocolo con ciclo de vida, negociación de capacidades y gestión de contexto con estado.

Vamos por capas.

Arquitectura lógica: cliente–servidor con capacidades declarativas

En MCP intervienen dos roles principales:

• Cliente MCP → normalmente el agente (por ejemplo, un agente en Copilot Studio).
• Servidor MCP → servicio que expone herramientas, recursos y prompts.

El flujo no es simplemente “haz esta llamada HTTP”. Primero hay un proceso de inicialización y negociación.

Cuando el cliente se conecta:

1. Se establece el transporte.
2. El cliente envía un mensaje initialize.
3. El servidor responde con:
   • versión del protocolo soportada
   • capacidades disponibles
   • metadata relevante

Es similar al handshake en protocolos como HTTP/2 o WebSocket, pero orientado a capacidades semánticas.

Esto permite:

• Versionado controlado
• Evolución del protocolo sin romper compatibilidad
• Descubrimiento dinámico de funcionalidades

Formato de mensajes: JSON-RPC 2.0

MCP utiliza JSON-RPC 2.0 como formato estructural de mensajes.

Esto significa que cada interacción tiene esta forma:

{
  "jsonrpc": "2.0",
  "id": "abc123",
  "method": "tools/call",
  "params": {
    ...
  }
}

Y la respuesta:

{
  "jsonrpc": "2.0",
  "id": "abc123",
  "result": {
    ...
  }
}

¿Por qué JSON-RPC? Porque:

• Es ligero.
• Permite correlación request/response mediante id.
• Soporta notificaciones (mensajes sin respuesta).
• Es agnóstico del transporte.

No es REST.

No es GraphQL.

Es un modelo de invocación procedural estructurada, más cercano a RPC tradicional.

Descubrimiento dinámico de capacidades

Uno de los puntos más potentes de MCP es que el cliente no necesita “conocer” previamente las herramientas.

Después del handshake, el cliente puede invocar métodos como:

• tools/list
• resources/list
• prompts/list

El servidor responde con descripciones estructuradas:

{
  "name": "createTicket",
  "description": "Crea un ticket en el sistema interno",
  "inputSchema": { ... }
}

Aquí ocurre algo crítico para agentes como Copilot:

👉 La descripción textual forma parte del razonamiento del LLM.
👉 El inputSchema define los parámetros estructurados que el modelo puede generar.

Esto convierte MCP en un puente entre:

• Mundo probabilístico (LLM)
• Mundo determinista (API / backend)

Invocación de herramientas

Cuando el modelo decide usar una herramienta:

1. Genera la intención estructurada.
2. El cliente traduce eso a una llamada MCP tools/call.
3. El servidor ejecuta la lógica real.
4. Devuelve un resultado estructurado.
5. El resultado se reinyecta en el contexto del modelo.

Ejemplo simplificado:

{
  "method": "tools/call",
  "params": {
    "name": "getOrderStatus",
    "arguments": {
      "orderId": "84729"
    }
  }
}

El servidor responde con:

{
  "result": {
    "status": "En tránsito",
    "estimatedDelivery": "mañana"
  }
}

Ese resultado no se muestra sin más: se vuelve input del LLM para continuar la conversación.

Gestión de estado

A diferencia de HTTP puro, MCP está diseñado para conexiones con estado lógico.

Esto implica:

• Contexto persistente durante la sesión
• Posibilidad de mantener información entre llamadas
• Suscripciones a eventos (en algunos transportes)

No es estrictamente stateless como REST tradicional.

El modelo conceptual es más cercano a:

• WebSocket con semántica RPC
• Canal bidireccional con negociación de capacidades

Transportes soportados

MCP es independiente del transporte, pero define mecanismos estándar:

stdio

El servidor corre como subproceso local.
El cliente envía mensajes JSON por STDIN y recibe por STDOUT.

Uso típico:

• Integraciones locales
• Entornos de desarrollo
• Plugins

Ventaja:

• Baja latencia
• Aislamiento sencillo

Streamable HTTP

El servidor expone un endpoint HTTP que acepta mensajes JSON-RPC.

Puede incluir:

• Streaming de resultados
• Respuestas parciales
• Comunicación bidireccional

Este modelo es el más habitual en entornos cloud y empresariales.

Seguridad y control

MCP no impone un sistema de autenticación concreto, pero:

• Permite autenticación a nivel de transporte (OAuth, API Key, etc.)
• Exige validación de origen en escenarios HTTP
• Considera las herramientas como superficies sensibles

El punto clave: Las descripciones de herramientas pueden influir en el razonamiento del modelo. Por tanto, un servidor MCP debe considerarse un componente crítico desde el punto de vista de seguridad.

Flujo completo resumido (end-to-end)

1. Cliente conecta.
2. Handshake initialize.
3. Descubrimiento de herramientas.
4. El usuario hace una pregunta.
5. El modelo decide usar una tool.
6. Cliente llama a tools/call.
7. Servidor ejecuta backend real.
8. Resultado vuelve al modelo.
9. El modelo genera respuesta final.

Es un ciclo híbrido entre:

• Orquestación semántica
• Ejecución determinista

Por qué esto es arquitectónicamente relevante

Desde el punto de vista de arquitectura de agentes:

MCP:

• Separa razonamiento de ejecución.
• Permite versionar capacidades.
• Reduce acoplamiento entre agente y backend.
• Facilita reutilización multi-plataforma.
• Permite gobernanza centralizada de capacidades.

En términos de diseño de sistemas, es un patrón de: “Capability Exposure Layer para agentes LLM”

Conclusión técnica

MCP no es simplemente un conector ni una API wrapper. Es:

• Un protocolo RPC estructurado.
• Con negociación de capacidades.
• Con descubrimiento dinámico.
• Con soporte de estado.
• Diseñado específicamente para interacción LLM ↔ sistemas.

Y ese diseño es lo que lo hace especialmente potente cuando se integra con plataformas de agentes como Copilot Studio.

¿Por qué MCP encaja tan bien con Copilot Studio?

Microsoft incorporó soporte de MCP en Copilot Studio para que los makers puedan conectar servidores MCP existentes y convertirlos en capacidades del agente con menos fricción.

Descubrimiento dinámico y menos mantenimiento

En Copilot Studio, las tools/resources de un servidor MCP se heredan automáticamente (nombre, descripción, inputs/outputs) y se actualizan dinámicamente: si el servidor añade, cambia o elimina herramientas, Copilot Studio refleja esos cambios y retira lo obsoleto. Esto reduce mucho el “trabajo invisible” de mantenimiento.

Gobernanza y seguridad “enterprise” vía infraestructura de conectores

Los MCP servers se exponen a Copilot Studio usando infraestructura de conectores, lo que habilita controles como VNet integration, DLP (Data Loss Prevention) y múltiples métodos de autenticación.

Además, el onboarding del MCP server contempla None / API Key / OAuth 2.0.

Nota importante: para usar MCP en Copilot Studio, Generative Orchestration debe estar habilitado.

«Un servidor, muchas capacidades»

Un servidor MCP puede agrupar herramientas relacionadas (lecturas + acciones) de forma coherente, lo que facilita que el agente encadene pasos en una misma conversación (descubrir → consultar → actuar). Es justo el tipo de “paquete de capacidades” que acelera la creación de agentes útiles.

MCP vs Conectores Power Platform

En Copilot Studio te puedes encontrar MCP servers y connectors lado a lado. No son equivalentes; son dos estrategias:

• MCP (dinámico): el agente “descubre” tools desde el servidor, y si cambian, se actualiza sin reconfigurar.
• Connector (más control maker): sueles tener más control para ajustar descripciones/inputs y, por tanto, afinar el comportamiento del orquestador.

Regla práctica:

• Elige MCP si quieres portabilidad, actualización automática y/o agrupación de capacidades detrás de un servidor (especialmente si tu organización trabaja con más de una plataforma de agentes).
• Elige conectores si necesitas control fino sobre cómo se describen acciones/herramientas al LLM (orquestación) o gobernanza más granular “por acción” según el caso.

Y lo más realista: puedes usar ambos en el mismo agente.

Cómo conectar un servidor MCP a Copilot Studio

Pasos:

1. En tu agente, ve a Tools → Add a tool → New tool → Model Context Protocol.
2. Rellena Server name, Server description y Server URL (la descripción ayuda al orquestador a decidir cuándo llamarlo).
3. Configura autenticación: None, API key o OAuth 2.0.
4. Crea/elige la connection y finaliza con Add to agent.

Buenas prácticas (seguridad y fiabilidad) cuando expones capacidades por MCP

MCP habilita acceso a datos y ejecución de acciones; por diseño es potente, y por eso la especificación insiste en controles de seguridad:

• Consentimiento y control del usuario antes de acceder a datos o invocar herramientas.
• Privacidad y minimización: compartir solo lo necesario, con controles de acceso.
• Tool safety: tratar herramientas como rutas de ejecución “sensibles”; las descripciones deben considerarse no confiables si no provienen de servidores de confianza.
• En Streamable HTTP, validar Origin para mitigar DNS rebinding, usar localhost en escenarios locales y aplicar autenticación adecuada.
• Para OAuth, la especificación se apoya en prácticas modernas (OAuth 2.1, uso de Authorization: Bearer, PKCE, HTTPS, etc.).

Y una recomendación “de trinchera”: monitoriza y gobierna. En integraciones reales se han reportado vulnerabilidades en servidores MCP concretos (especialmente cuando se combinan componentes) que refuerzan la importancia de hardening, validaciones y políticas.

Casos de uso típicos (donde MCP brilla)

• APIs internas: ERP, CRM propio, catálogo de producto, pricing, logística. Publicas tools bien diseñadas (“getOrderStatus”, “createReturn”, “reserveStock”) y el agente actúa.
• Knowledge servers: exponer recursos normalizados (documentos, procedimientos, SLAs, KB) para grounding de respuestas.
• Estrategia multi-plataforma: un mismo MCP server puede servir a Copilot Studio y a otros clientes MCP compatibles, reduciendo duplicidad de integraciones.

MCP no es “otra integración más”

MCP es un estándar para que tus agentes conecten de forma consistente con datos y acciones, y en Copilot Studio aporta un camino muy directo para convertir sistemas corporativos en capacidades del agente con menos mantenimiento y con opciones de seguridad/gobernanza propias del ecosistema Power Platform.

¿Quieres saber más sobre las soluciones de inteligencia artificial generativa de Microsoft? En DQS/ te asesoramos. ¿Por qué no nos preguntas cómo podemos ayudarte?