Model Context Protocol (MCP): de los primeros principios a la producción
Arquitectura, herramientas, recursos, seguridad, integración empresarial y un MCP Server completo en Python
Guía técnica actualizada para la Especificación MCP 2026-07-28, con investigación verificada el 23 de agosto de 2026.
Por João Ricardo Dutra••Material completo
Nota de versión. Esta guía se escribió con base en la Especificación MCP de 2026-07-28, la especificación vigente en el momento de la investigación. Los tutoriales antiguos suelen enseñar el handshake initialize/initialized, las sesiones de protocolo, Roots, Sampling, Logging y HTTP+SSE como si continuaran vigentes. El núcleo de 2026-07-28 no mantiene estado: se retiraron el handshake y la sesión de protocolo; Roots, Sampling y Logging quedaron en desuso; Tasks es una extensión oficial; y Streamable HTTP es el transporte remoto moderno. El comportamiento heredado se sigue explicando cuando ayuda a comprender clientes y servidores existentes. [2][3]
1. Introducción: el problema de integración que MCP resuelve
Imagine una empresa mediana con un CRM, una base de datos relacional, varias API REST internas, Google Drive, GitHub, un sistema de tickets y una aplicación de gestión de contactos. Ahora imagine que la empresa quiere utilizar varias experiencias de IA: un asistente de codificación, un agente de soporte, un asistente de ventas, un asistente de conocimiento interno y un agente de automatización.
La idea obvia parece simple: dejar que cada IA llame a los sistemas que necesita. La realidad de la ingeniería es menos simple. Un producto de IA espera un complemento propietario. Otro espera definiciones de funciones JSON integradas en cada solicitud de modelo. Un tercero utiliza su propio SDK de conector. Un cuarto puede llamar a REST directamente, pero solo después de crear un puente personalizado que traduzca la intención del modelo en solicitudes HTTP, maneje la autenticación, transforme las respuestas y explique las operaciones disponibles para el modelo.
Acaba de crear una matriz de integración. Si cinco aplicaciones de IA necesitan acceso a diez sistemas empresariales, la superficie conceptual puede acercarse a 5 x 10 = 50 relaciones de integración. No todas las celdas requieren una base de código distinta, pero cada combinación puede introducir diferencias en el descubrimiento, el formato del esquema, la autorización, el ciclo de vida, el manejo de errores, el empaquetado y la configuración específica del producto.
MCP se creó para reducir esta duplicación estandarizando el límite entre una aplicación de IA y las capacidades externas. En lenguaje sencillo:
Model Context Protocol es un protocolo abierto a través del cual las aplicaciones de IA pueden descubrir e interactuar con herramientas, recursos y flujos de trabajo reutilizables expuestos por servidores externos.
Es por eso que a menudo se compara MCP con USB-C para integraciones de IA. La analogía es útil: un conector común reduce el número de adaptadores personalizados. Pero está incompleto. USB-C especifica una interfaz física y eléctrica. MCP es un protocolo de software y la interoperabilidad real aún depende de la política de seguridad, las versiones de protocolo admitidas, las extensiones opcionales, el comportamiento del host, la calidad de las herramientas y las opciones de productos específicas del proveedor.
Una mejor pregunta para completar esta guía es: ¿Qué pasaría si una aplicación de IA pudiera preguntarle a un sistema qué capacidades expone, comprender sus esquemas, invocarlos a través de un protocolo estándar y reutilizar la misma integración en múltiples hosts compatibles?
Ese es el espacio problemático que aborda MCP.
2. El problema antes de MCP
Antes de MCP, la integración de la IA al sistema generalmente se basaba en uno o más de los siguientes patrones:
Integraciones REST personalizadas. Su aplicación escribe código personalizado que llama a una API y luego convierte manualmente el resultado en contexto de modelo.
Llamada a funciones específicas del modelo. Usted describe las funciones en el esquema esperado por un proveedor de modelo específico e implementa el ciclo de ejecución usted mismo.
Complementos y conectores propietarios. Un proveedor define un manifiesto, un SDK, un modelo de empaquetado o un contrato de mercado.
Integraciones específicas de SDK. Los marcos proporcionan adaptadores, pero el adaptador a menudo pertenece a ese marco y no a un protocolo neutral.
Inyección de contexto manual. Un desarrollador recupera registros de bases de datos, archivos o respuestas de API y los coloca directamente en el mensaje.
Ninguno de estos enfoques es inherentemente incorrecto. Una Function Calling directa puede ser la solución más limpia para una aplicación con tres operaciones internas. El problema de escala aparece cuando es necesario reutilizar capacidades en muchos hosts de IA.
Considere cinco aplicaciones de IA y diez sistemas empresariales. Sin un protocolo compartido, es posible que cada consumidor necesite aprender a autenticar, descubrir, describir y llamar a cada proveedor. MCP cambia la unidad arquitectónica: en lugar de pensar principalmente en términos de "IA A se integra con el Sistema X", puede construir un servidor MCP para el Sistema X y permitir que los hosts compatibles lo consuman.
Conceptualmente:
Antes de un protocolo compartido
IA-1 ---- puente personalizado ---- CRM
IA-1 ---- puente personalizado ---- GitHub
IA-2 ---- otro puente --- CRM
IA-2 ---- otro puente --- GitHub
...
Con MCP
Hosts de IA ---- MCP ---- Servidor CRM MCP ---- CRM/API
\--- MCP ---- Servidor GitHub MCP - GitHub/API
La promesa se construye una vez, se integra con múltiples clientes compatibles con MCP. La redacción cuidadosa importa. MCP no garantiza que todos los clientes admitan todas las capacidades opcionales, extensiones, patrones de autenticación, funciones de interfaz de usuario o permisos de productos. El protocolo reduce la duplicación de integración; no borra las diferencias del producto.
3. Historia del MCP
Anthropic anunció el Model Context Protocol el 25 de noviembre de 2024 como un estándar abierto para conectar asistentes de IA a los sistemas donde residen los datos y las herramientas. La versión inicial incluía la especificación, SDK, soporte de servidor local en Claude Desktop y servidores de ejemplo para servicios como Google Drive, GitHub, Slack, Postgres, Git y automatización del navegador. [1]
El momento fue importante. Las llamadas a funciones ya habían hecho que fuera normal que los modelos de lenguaje solicitaran operaciones externas, pero cada proveedor y marco exponía esa idea de manera diferente. Mientras tanto, las herramientas de desarrollo estaban demostrando que los modelos de lenguaje se volvían mucho más útiles cuando podían inspeccionar repositorios, bases de datos, archivos, terminales y contexto específico del proyecto. La pieza que faltaba era un límite de integración reutilizable.
La arquitectura de MCP también evoca un precedente exitoso de las herramientas de desarrollo: el Protocolo de servidor de idiomas (LSP). LSP redujo la necesidad de que cada editor implementara integraciones personalizadas para cada lenguaje de programación. MCP aborda un dominio diferente, pero la lección arquitectónica es similar: un protocolo compartido puede separar los hosts de los proveedores de capacidades y permitir que los ecosistemas crezcan de forma independiente.
La adopción se aceleró durante 2025 a medida que las herramientas de codificación de IA y las plataformas de agentes agregaron soporte MCP y aparecieron miles de servidores comunitarios. El auge de los agentes de IA que utilizan herramientas hizo que la interoperabilidad fuera más urgente: un agente que puede razonar pero no puede llegar de manera confiable a los sistemas empresariales tiene un valor operativo limitado.
Un hito importante en la gobernanza llegó el 9 de diciembre de 2025, cuando MCP contribuyó a la Fundación Agentic IA (AAIF) de la Fundación Linux, junto con otros proyectos de IA agente. El modelo de base neutral amplió la participación de la industria mientras que la comunidad de mantenedores de MCP continuó con la gobernanza técnica. [14] [15]
El rediseño de protocolo más grande hasta el momento se envió el 28 de julio de 2026. La revisión 2026-07-28 convirtió el núcleo en apátrida, eliminó el protocolo de enlace de inicialización obligatorio y las sesiones de protocolo, introdujo un RPC de servidor/descubrimiento opcional, agregó encabezados HTTP compatibles con puertas de enlace y sugerencias de caché, formalizó extensiones, movió Tareas a una extensión, autorizó reforzada y desaprobó Roots, Sampling, Logging y HTTP+SSE heredado. [2]
La importante lección histórica es que el MCP no está congelado. Si aprendió MCP en un tutorial de 2024 o 2025, parte de su modelo mental ahora es heredado. Los equipos de producción deben versionar sus suposiciones tal como versionan un contrato API.
4. Lo que realmente resuelve MCP
MCP sustituye adaptadores punto a punto repetidos por un límite de protocolo reutilizable.
MCP resuelve principalmente un problema de estandarización e interoperabilidad en el límite entre los hosts de IA y las capacidades externas.
Ayuda con la capacidad de descubrimiento. Un cliente puede obtener un catálogo de herramientas, recursos e indicaciones en lugar de codificar cada capacidad en una solicitud modelo. Ayuda con la integración de herramientas al brindar a las operaciones formas de protocolo predecibles. Ayuda con la integración del contexto al brindar a las aplicaciones una forma estandarizada de exponer los recursos direccionables. Ayuda con la reutilización porque varios hosts compatibles pueden consumir un servidor MCP. Ayuda a separar las preocupaciones porque el proveedor del modelo no necesita conocer la implementación interna de un CRM, una base de datos, un sistema de tickets o una puerta de enlace API.
Para los desarrolladores, esto reduce el código adhesivo. Para los proveedores de aplicaciones de IA, crea un límite en el ecosistema. Para las empresas, permite la gobernanza en torno a capacidades y servidores aprobados. Para los equipos de API y plataforma, proporciona una fachada controlada para los agentes de IA sin reemplazar las API y los servicios que ya se ejecutan debajo. Para los usuarios finales, puede hacer que un asistente sea útil en el entorno donde realmente se trabaja.
El protocolo no resuelve por sí solo la calidad semántica. Una herramienta do_everything mal llamada sigue siendo deficiente. MCP no otorga acceso automáticamente, no decide la política de autorización, no detiene la inyección de prompts, no hace que las operaciones destructivas sean seguras ni garantiza que cada modelo elija la herramienta adecuada. Piense en MCP como una infraestructura para exponer capacidades, no como un sustituto del diseño de aplicaciones y la ingeniería de seguridad.
5. Arquitectura MCP: host, cliente y servidor
El host controla la experiencia de IA; cada conexión de cliente se comunica con un servidor MCP.
MCP utiliza tres términos que son fáciles de confundir: Host, Cliente y Servidor.
Un host MCP es la aplicación de IA con la que interactúa el usuario: un agente IDE, un asistente de escritorio, un copiloto empresarial o su propia aplicación. El host es propietario de la experiencia del usuario, la orquestación del modelo, los permisos y la política.
Un cliente MCP es el componente de protocolo dentro del host que se comunica con un servidor MCP. Un host puede mantener múltiples relaciones de cliente a servidor. En la documentación del producto, el cliente puede ser en gran medida invisible porque es una parte interna del host.
Un servidor MCP expone capacidades. Puede incluir un sistema de archivos local, una base de datos, una API SaaS, una herramienta de línea de comandos, un servicio interno o lógica empresarial.
Usuario
|
v
Aplicación de IA/host MCP
|
v
Cliente MCP
|
| Mensajes MCP (JSON-RPC 2.0)
v
Servidor MCP
|
v
Aplicación/API/Base de datos
Un host puede conectarse a muchos servidores:
Asistente / Anfitrión de IA
|
+-- Cliente MCP --> Servidor GitHub MCP
|
+-- Cliente MCP --> Servidor MCP de base de datos
|
+-- Cliente MCP --> Servidor CRM MCP
|
+-- Cliente MCP --> Contactos Servidor MCP
Esto es importante porque un agente potencialmente puede combinar capacidades. Un usuario podría preguntar: "Encuentre el incidente abierto, identifique al propietario del servicio en el directorio y redacte una actualización". El host puede permitir que el modelo utilice un servidor de mesa de servicio, un servidor de directorio interno y un servidor de documentación en un ciclo de razonamiento.
La distinción anfitrión/cliente también es un límite de seguridad. El anfitrión decide qué ve el modelo y qué puede ejecutar. El servidor anuncia capacidades, pero nunca debe asumir que un cliente aplicará sus sugerencias correctamente. La validación sensible a la seguridad también pertenece al lado del servidor.
6. Fundamentos del protocolo MCP
Los mensajes MCP se basan en JSON-RPC 2.0, un formato ligero de llamada a procedimientos remotos. JSON-RPC define solicitudes, respuestas, notificaciones, identificadores y formas de error. MCP define los métodos y modelos de datos que viajan dentro de ese sobre.
Una notificación es un mensaje que no espera respuesta. Los errores utilizan el objeto de error JSON-RPC. Luego, la especificación del protocolo agrega métodos específicos de MCP, como enumerar o llamar a herramientas y recursos de lectura.
6.1 El núcleo sin estado
Aquí es donde el MCP actual difiere marcadamente de los tutoriales más antiguos. Las revisiones de protocolo anteriores utilizaban una solicitud de inicialización, una notificación inicializada, capacidades negociadas durante un protocolo de enlace y podían asociar el trabajo HTTP con un Mcp-Session-Id. El núcleo del 28 de julio de 2026 eliminó ese protocolo de enlace obligatorio y la sesión a nivel de protocolo. Cada solicitud se describe a sí misma y lleva metadatos de protocolo/cliente; una llamada opcional de servidor/descubrimiento permite a un cliente solicitar capacidades del servidor antes de realizar otro trabajo. [2]
Por lo tanto, una secuencia conceptual moderna es:
El host está configurado con un servidor MCP
|
v
El cliente se inicia/se conecta al servidor
|
+--> servidor opcional/descubrir
|
+--> herramientas/lista, recursos/lista, indicaciones/lista
|
v
El modelo ve las definiciones de herramientas seleccionadas
|
v
Modelo solicita una operación
|
v
herramientas/llamada
|
v
El servidor ejecuta la capacidad empresarial
|
v
El resultado de la herramienta regresa al host
|
v
El anfitrión incorpora el resultado en el contexto del modelo.
Para Streamable HTTP, la nueva revisión puede llevar encabezados MCP-Protocol-Version, Mcp-Method y, para operaciones con nombre, Mcp-Name. Las puertas de enlace pueden enrutar, medir o aplicar políticas mediante encabezados en lugar de analizar cada cuerpo JSON. Las respuestas de lista/lectura también pueden anunciar sugerencias de caché como ttlMs y cacheScope. [2]
6.2 ¿Qué pasó con la negociación de capacidades?
Las capacidades siguen siendo importantes, pero ya no están vinculadas a un protocolo de enlace de conexión requerido. La identidad y las capacidades del cliente pueden viajar en metadatos de solicitud, mientras que server/discover proporciona un descubrimiento de servidor inicial opcional. Esto hace que el escalado horizontal ordinario sea mucho más fácil: una solicitud puede llegar a cualquier instancia compatible en lugar de requerir sesiones de protocolo fijo.
6.3 Ciclo de vida heredado que aún encontrarás
Si opera clientes o servidores con revisiones de la era 2025, espere el ciclo de vida anterior:
conectar -> inicializar -> negociación de versión/capacidad -> inicializado
-> descubrimiento -> invocación -> finaliza la sesión
Trátelo como conocimiento de compatibilidad heredado, no como un diseño para copiar en una nueva implementación de 2026.
7. Primitivas de MCP: herramientas, recursos e indicaciones
Las primitivas del servidor exponen acciones, contexto, flujos reutilizables y operaciones prolongadas.
El modelo mental para principiantes más útil es comprender las tres primitivas del servidor central según quién las controla. La documentación actual del SDK de Python resume bien la distinción: las herramientas son operaciones controladas por modelos; los recursos son un contexto controlado por la aplicación; Los mensajes son plantillas reutilizables seleccionadas por el usuario. [5][7] [8]
7.1 Herramientas
Una herramienta representa una operación que el modelo puede invocar. Los ejemplos incluyen:
• buscar_contactos
• crear_contacto
• enviar_correo electrónico
• base de datos_consulta
• crear_ticket
• obtener_clima
Una definición de herramienta útil le dice al modelo tres cosas: cómo se llama la operación, qué hace y qué argumentos espera. En un SDK de alto nivel, las sugerencias de tipo pueden generar el esquema JSON automáticamente.
Conceptualmente, una herramienta se puede describir así:
{
"nombre": "buscar_contactos",
"description": "Buscar contactos por nombre, correo electrónico, empresa o teléfono.",
"esquema de entrada": {
"tipo": "objeto",
"propiedades": {
"consulta": {"tipo": "cadena"},
"límite": {"tipo": "entero", "mínimo": 1, "máximo": 50}
},
"requerido": ["consulta"]
}
}
La descripción no es cosmética. El LLM utiliza el nombre, la descripción, el esquema de entrada, la solicitud del usuario, las instrucciones del sistema y las alternativas disponibles para decidir si la herramienta es relevante. Por lo tanto, el diseño de herramientas es en parte diseño de API y en parte diseño de interfaz de modelo.
7.2 Recursos
Un recurso expone datos que una aplicación puede leer y colocar en contexto. Los recursos utilizan URI o plantillas de URI:
• contactos://todos
• contactos://123
• empresa://políticas/seguridad
• base de datos://esquema/clientes
La diferencia clave es la intención. Una herramienta dice "realizar una operación". Un recurso dice: "aquí hay información direccionable que se puede cargar". La lectura de contactos://123 no debe eliminar, enviar, implementar ni cobrar nada.
Una regla útil es:
Si el significado principal es leer esta información, considere un recurso. Si el significado principal es realizar esta operación, considere una herramienta.
Esa regla no es absoluta. Una herramienta get_contact puede seguir siendo útil porque la búsqueda basada en modelos puede ser más sencilla que la navegación de recursos en algunos hosts. MCP le ofrece opciones de modelado; la respuesta correcta depende de cómo se consumirá la capacidad.
7.3 Prompts
Un mensaje MCP es una plantilla de mensaje reutilizable que generalmente selecciona el usuario a través de la interfaz de usuario del cliente. Está más cerca de un flujo de trabajo guardado o un comando de barra diagonal que de una operación del lado del servidor. [8]
Por ejemplo, un servidor de Contactos puede exponer prepare_follow_up(contact_id, propósito). El mensaje puede ofrecer instrucciones que pidan al modelo que lea el contacto seleccionado, resuma notas anteriores y redacte un mensaje de seguimiento conciso. El mensaje no envía el mensaje por sí solo. Aporta instrucciones estructuradas a la conversación.
Herramienta -> el modelo puede elegir una acción
Recurso -> la aplicación puede cargar contexto
Mensaje -> el usuario puede elegir una plantilla reutilizable
8. Capacidades del lado del cliente y el rediseño del protocolo
Los tutoriales de MCP más antiguos a menudo presentan raíces, muestreo y registro del lado del cliente como capacidades de protocolo principales.
Las raíces permiten a los clientes exponer las raíces del sistema de archivos o información de alcance similar.
El muestreo permite a los servidores solicitar la generación de modelos a través del cliente.
El registro proporcionó mensajes de registro a nivel de protocolo.
A partir de MCP 2026-07-28, Roots, Sampling y Logging están obsoletos. Permanecen durante una ventana de migración, pero sus mantenedores recomiendan explícitamente que las nuevas implementaciones no los adopten. La guía es modelar el alcance del sistema de archivos a través de parámetros/recursos/configuración del servidor de herramientas ordinarias, llamar a las API del proveedor de modelos directamente para un comportamiento similar al de muestreo y utilizar el registro operativo estándar como stderr para stdio y observabilidad de estilo OpenTelemetry para servicios implementados. [2][3]
El rediseño del protocolo 2026 también cambia la forma en que un servidor puede solicitar información adicional al cliente. En lugar de asumir un canal bidireccional persistente, las solicitudes de ida y vuelta múltiples (MRTR) permiten que una operación de servidor devuelva un resultado input_required que describe lo que necesita. El cliente puede recopilar la información y volver a intentar la operación original con las respuestas adjuntas. Esto es más amigable para la infraestructura HTTP sin estado. [2]
La elicitación (pedir al usuario/cliente información adicional) pertenece, por lo tanto, a este nuevo modelo de ida y vuelta en lugar de ser considerada como "el servidor puede volver a llamar arbitrariamente al cliente en cualquier momento". El soporte aún varía según el host. Puede existir una característica de protocolo en la especificación mientras que un producto la omite, la restringe o la expone solo en ciertos planes. Distinga siempre la capacidad del protocolo de la capacidad del producto.
9. Tareas y operaciones de larga duración
Algunos trabajos no encajan cómodamente en un ciclo corto de solicitud/respuesta. Generar un informe con millones de filas, procesar miles de documentos, ejecutar una implementación o realizar una migración grande puede llevar minutos u horas.
MCP experimentó con Tareas en el núcleo 2025-11-25. En la generación 2026-07-28, Tasks pasó a la extensión oficial io.modelcontextprotocol/tasks. Esto es importante: las tareas son reales, pero no forman parte del protocolo central mínimo. Ambos lados deben soportar la extensión. [2][4]
Una tarea puede tener estos estados: [4]
Estado Significado
trabajando La operación aún está en ejecución.
input_required El servidor necesita entrada adicional del cliente.
completado La operación finalizó exitosamente.
La ejecución fallida finalizó con un error JSON-RPC.
La cancelación fue solicitada/aceptada; cancelación
cancelado
Es posible que no siempre se respete instantáneamente.
La extensión actual utiliza un modelo de creación dirigido al servidor. Una llamada a una herramienta puede devolver un identificador de tarea; el cliente puede sondear con tareas/obtener, proporcionar información solicitada a través de tareas/actualización y solicitar cancelación a través de tareas/cancelar. El concepto anterior de tareas/lista se eliminó porque es difícil alcanzar una lista amplia de manera segura en una arquitectura sin estado. [3][4]
La lección de diseño es más amplia que las Tareas: las acciones de IA de larga duración necesitan un ciclo de vida explícito. "El modelo llamado herramienta" no es suficiente para representar el progreso, los reintentos, la entrada del usuario, la cancelación o la semántica del resultado final.
10. Transportes MCP: stdio y Streamable HTTP
Los servidores locales suelen usar stdio; las implementaciones remotas usan Streamable HTTP.
El protocolo define mensajes; el transporte determina cómo se mueven esos bytes entre el cliente y el servidor.
Las opciones modernas son sencillas:
Transporte Características de mejor ajuste
El anfitrión lanza un proceso hijo y
se comunica a través de
stdio Servidores MCP locales
entrada estándar/salida estándar. Sin escucha de red
se requiere.
Transporte Características de mejor ajuste
Punto final HTTP real, funciona con
TLS, proxies, identidad, puertas de enlace,
Servidores MCP remotos/implementados HTTP que se pueden transmitir
balanceadores de carga y horizontales
escalada.
Oficialmente obsoleto; no
Solo compatibilidad con HTTP+SSE heredado
elegir para nuevos sistemas.
El SDK oficial de Python refleja esto directamente: mcp.run() tiene por defecto stdio, mientras que
mcp.run(transport="streamable-http", port=3001) expone /mcp a través de HTTP. La documentación del SDK etiqueta explícitamente a SSE como heredado y dice que no se deben construir nuevos sistemas sobre él. [6]
10.1 Servidor MCP local
Con stdio, un host como un IDE o una aplicación de escritorio inicia el servidor:
Las ventajas incluyen bajos gastos de instalación, ningún puerto de red expuesto y acceso natural al contexto de desarrollo local. Los riesgos incluyen la ejecución arbitraria de código local: instalar un servidor MCP aleatorio es operativamente similar a instalar cualquier otro paquete que no sea de confianza.
10.2 Servidor MCP remoto
Un servidor remoto se ejecuta detrás de la infraestructura HTTP:
Anfitrión de IA
|
HTTPS
v
Equilibrador de carga/puerta de enlace
|
v
Instancias del servidor MCP
|
v
API empresariales/datos
La implementación remota introduce TLS, DNS, OAuth, política de red, límites de velocidad, multiinquilino, observabilidad y escalabilidad. El núcleo 2026 sin estado hace que este modelo operativo sea mucho más limpio porque las solicitudes de protocolo ya no dependen de una sesión MCP fija.
11. MCP vs REST API: ¿MCP está reemplazando a las API?
No. MCP y REST suelen resolver diferentes capas del problema.
Una API REST es una interfaz de software para recursos y operaciones a través de HTTP. A menudo es el límite de integración empresarial duradero que utilizan las aplicaciones web, las aplicaciones móviles, los socios, los servicios y la automatización. MCP es un protocolo de interoperabilidad orientado a la IA que puede exponer capacidades seleccionadas de una manera que los hosts de IA puedan descubrir e invocar.
Un servidor MCP puede llamar internamente a una API REST:
Esto significa que una empresa no necesita reemplazar sus API para adoptar MCP. De hecho, una organización madura puede preservar el ciclo de vida, la seguridad, la limitación de velocidad, los contratos y la observabilidad de su API existente al mismo tiempo que agrega una capa MCP que traduce herramientas amigables para los agentes en llamadas API controladas.
REST sigue siendo útil para la integración determinista de software a software. MCP agrega capacidad de descubrimiento y descripciones de capacidades orientadas a la IA. Los dos son complementarios.
12. MCP frente a llamadas a funciones
La llamada a funciones es generalmente una capacidad de una API modelo: usted proporciona al modelo esquemas de función/herramienta, devuelve una solicitud estructurada para llamar a uno, su aplicación lo ejecuta y usted envía el resultado.
MCP estandariza cómo un host de IA se conecta a un proveedor de capacidades externo que puede publicar herramientas, recursos, indicaciones y extensiones.
Función de dimensión que llama a MCP
Generalmente definido por un
Propiedad Protocolo/ecosistema abierto
API de modelo/proveedor
La aplicación normalmente proporciona esquemas en el servidor y expone catálogos a través de
Descubrimiento
cada método de protocolo de integración
stdio o Streamable HTTP (más
Solicitud/respuesta de API del proveedor de transporte
compatibilidad heredada)
A menudo vinculado a uno Diseñado para su reutilización en
Reutilizar
hosts compatibles con la integración de aplicaciones/proveedores
Interoperabilidad de host a servidor plus
Modelo de alcance elige convocatorias estructuradas
primitivas/extensiones
Esquema y protocolo estándar específicos del proveedor, con
Dependencia del proveedor
El comportamiento del host específico del bucle de ejecución aún es posible
Pueden coexistir. Un host puede usar internamente la llamada a función nativa de un modelo para decidir que search_contacts debe ejecutarse, mientras que la capacidad real se descubre y ejecuta a través de MCP.
Una separación mental clara es: La llamada a función ayuda a un modelo a expresar una llamada de herramienta prevista. MCP ayuda a una aplicación a descubrir y ejecutar capacidades expuestas por servidores externos.
13. MCP frente a complementos y conectores propietarios
Los complementos y conectores propietarios suelen ser contratos de productos específicos. Pueden definir formatos de manifiesto, flujos de autenticación, mercados, reglas de empaquetado o SDK que funcionan muy bien dentro del ecosistema de un proveedor.
La ventaja de interoperabilidad de MCP es que la definición de capacidad del lado del servidor pertenece a un protocolo abierto. El mismo servidor MCP de contactos puede ser consumido potencialmente por un asistente de escritorio, un agente IDE, un copiloto empresarial o su propio host sin tener que volver a escribir el adaptador empresarial para cada producto.
Eso no elimina las capas propietarias. Un producto puede empaquetar servidores MCP en su propio formato de extensión, imponer un proceso de aprobación del mercado, exponer solo un subconjunto de primitivos o agregar políticas específicas de la organización. MCP estandariza el modelo de cableado y capacidad, no todas las experiencias del producto circundante.
14. Cómo una IA elige una herramienta MCP
El descubrimiento es sólo la mitad de la historia. Una vez que un cliente tiene herramientas, el anfitrión decide qué definiciones de herramientas poner a disposición del modelo. Luego, el modelo elige entre ellos basándose en varias señales:
1. Nombre de la herramienta. search_contacts es más fácil de hacer coincidir con una solicitud de búsqueda que contact_op.
2. Descripción. Una oración clara explica la intención y los límites. 3. Esquema de entrada. Los nombres y descripciones de los parámetros le dicen al modelo qué información se requiere. 4. Solicitud del usuario. "Buscar a María" apunta a la búsqueda, mientras que "agregar a María" apunta a la creación. 5. Instrucciones del sistema/desarrollador. El host puede prohibir escrituras, exigir confirmación o especificar flujos de trabajo. 6. Alternativas disponibles. Las herramientas superpuestas aumentan la ambigüedad. 7. Razonamiento modelo. El modelo estima qué acción hace avanzar mejor la tarea.
Para "¿Qué María en Contoso tiene un número de móvil que termina en 77?", search_contacts es semánticamente sólido porque puede filtrar. Para "Abrir el registro completo del contacto 41", get_contact es más preciso. Para "Eliminar contacto de prueba 99", eliminar_contacto es la operación con efectos secundarios peligrosos y debería estar sujeta a una política más estricta.
Un mal diseño de herramientas aumenta la probabilidad de error. Una herramienta llamada administrar_contacto (acción, carga útil) obliga al modelo a comprender un miniprotocolo adicional dentro de un esquema. Las herramientas explícitas reducen la ambigüedad y brindan a los hosts controles de permisos más granulares.
15. Cómo diseñar buenas herramientas MCP
Las buenas herramientas MCP parecen buenas API, pero con especial atención a cómo los modelos de lenguaje interpretan las descripciones.
15.1 Utilice nombres explícitos y responsabilidades limitadas
a menos que la operación genérica sea genuinamente la capacidad del dominio.
15.2 Escribir descripciones como contratos de comportamiento.
Una descripción útil establece lo que hace la herramienta, los límites importantes y lo que no hace cuando es probable que haya ambigüedad.
Malo:
"Maneja contactos". Mejor:
"Busca contactos por nombre parcial, correo electrónico, teléfono o empresa. Sólo lectura. Devuelve como máximo 50 coincidencias y no modifica los registros de contacto".
15.3 Hacer que los esquemas sean predecibles
Utilice tipos seguros, enumeraciones limitadas, campos obligatorios explícitos, longitudes máximas razonables e identificadores específicos de dominio. Evite las manchas gigantes de forma libre si hay campos estructurados disponibles.
15.4 Devolución de resultados estructurados
Las máquinas consumen estructura de forma más fiable que la prosa. Devuelve objetos de contacto con campos estables en lugar de un párrafo que el modelo debe analizar nuevamente.
15.5 Validar todo del lado del servidor
Los argumentos generados por el modelo son entradas que no son de confianza. Valide identificadores, longitudes, valores de enumeración, reglas comerciales, autorización y propiedad de recursos exactamente como lo haría con una API pública.
15.6 Diseño para idempotencia cuando sea posible
El comportamiento de reintento es más fácil cuando repetir una operación es seguro. Una lectura es naturalmente idempotente.
update_contact(id=7, phone="...") puede ser idempotente. create_contact generalmente no lo es a menos que use una clave de idempotencia o una regla de unicidad natural.
15.7 Separar lecturas y escrituras
Esto respalda la política granular. Un host puede permitir buscar_contactos sin permitir eliminar_contacto.
15.8 Trate las anotaciones como sugerencias, no como controles
El SDK de Python puede exponer anotaciones como read_only_hint, destructive_hint, idempotent_hint y open_world_hint. Estos pueden ayudar a los clientes con buen comportamiento a decidir si la confirmación es apropiada, pero no son medidas de seguridad. [7]
16. Proyecto Práctico: Aplicación de Gestión de Contactos con un Servidor MCP
Construiremos un sistema deliberadamente pequeño que haga visible cada capa.
Cada contacto tiene:
• id
• name
• email
• phone
• company
• notes
SQLite proporciona persistencia local. Python es una buena opción porque el SDK v2 oficial de MCP Python admite la especificación 2026-07-28 y expone una API MCPServer de alto nivel. Al momento de escribir este artículo, el SDK requiere Python 3.10+ y se puede instalar con uv add "mcp[cli]" o pip install "mcp[cli]". [5]
Nuestro objetivo de diseño es importante: la aplicación de contacto debe funcionar sin MCP. MCP es un adaptador de las capacidades empresariales, no el lugar donde reside la lógica empresarial.
Diseño del proyecto:
contacts-mcp/
├── pyproject.toml
├── contacts_service.py
├── server.py
└── contacts.db # created at runtime
17. Arquitectura de la aplicación de contacto
MCP se mantiene como un adaptador sobre lógica de negocio y persistencia reutilizables.
Asistente / Anfitrión de IA
|
v
Cliente MCP
|
v
Contactos Servidor MCP <-- adaptador de protocolo
|
v
ContactService <-- operaciones comerciales/de datos
|
v
SQLite
IA Assistant / Host es propietario del modelo y de la interacción del usuario. El cliente MCP habla el protocolo. Contactos MCP Server asigna herramientas/recursos/indicaciones de MCP a las capacidades de la aplicación. ContactService sabe cómo se almacenan y validan los contactos. SQLite conserva los registros.
Esta separación hace que el servicio sea reutilizable. Posteriormente, podría exponer el mismo ContactService a través de una API REST, una CLI, pruebas o un trabajo en segundo plano sin importar el código MCP a la capa de dominio.
18. Cree el servicio de contacto antes de MCP
Create contacts_service.py :
from __future__ import annotations
import sqlite3
from pathlib import Path
from typing import Any
class ContactService:
def __init__(self, db_path: str = "contacts.db") -> None:
self.db_path = Path(db_path)
self._initialize()
def _connect(self) -> sqlite3.Connection:
connection = sqlite3.connect(self.db_path)
connection.row_factory = sqlite3.Row
return connection
def _initialize(self) -> None:
with self._connect() as db:
db.execute(
"""
CREATE TABLE IF NOT EXISTS contacts (
id INTEGER PRIMARY KEY AUTOINCREMENT,
name TEXT NOT NULL,
email TEXT,
phone TEXT,
company TEXT,
notes TEXT
)
"""
)
@staticmethod
def _row_to_dict(row: sqlite3.Row | None) -> dict[str, Any] | None:
return dict(row) if row is not None else None
def create_contact(
self,
name: str,
email: str | None = None,
phone: str | None = None,
company: str | None = None,
notes: str | None = None,
) -> dict[str, Any]:
name = name.strip()
if not name:
raise ValueError("name must not be empty")
with self._connect() as db:
cursor = db.execute(
"""
INSERT INTO contacts(name, email, phone, company, notes)
VALUES (?, ?, ?, ?, ?)
""",
(name, email, phone, company, notes),
)
contact_id = int(cursor.lastrowid)
contact = self.get_contact(contact_id)
assert contact is not None
return contact
def get_contact(self, contact_id: int) -> dict[str, Any] | None:
with self._connect() as db:
row = db.execute(
"SELECT * FROM contacts WHERE id = ?", (contact_id,)
).fetchone()
return self._row_to_dict(row)
def list_contacts(self, limit: int = 50) -> list[dict[str, Any]]:
limit = max(1, min(limit, 200))
with self._connect() as db:
rows = db.execute(
"SELECT * FROM contacts ORDER BY name LIMIT ?", (limit,)
).fetchall()
return [dict(row) for row in rows]
Continuar el mismo archivo:
def search_contacts(
self, query: str, limit: int = 20
) -> list[dict[str, Any]]:
query = query.strip()
if not query:
return []
limit = max(1, min(limit, 50))
pattern = f"%{query}%"
with self._connect() as db:
rows = db.execute(
"""
SELECT *
FROM contacts
WHERE name LIKE ?
OR email LIKE ?
OR phone LIKE ?
OR company LIKE ?
ORDER BY name
LIMIT ?
""",
(pattern, pattern, pattern, pattern, limit),
).fetchall()
return [dict(row) for row in rows]
def update_contact(
self,
contact_id: int,
name: str | None = None,
email: str | None = None,
phone: str | None = None,
company: str | None = None,
notes: str | None = None,
) -> dict[str, Any]:
current = self.get_contact(contact_id)
if current is None:
raise LookupError(f"contact {contact_id} not found")
values = {
"name": current["name"] if name is None else name.strip(),
"email": current["email"] if email is None else email,
"phone": current["phone"] if phone is None else phone,
"company": current["company"] if company is None else company,
"notes": current["notes"] if notes is None else notes,
}
if not values["name"]:
raise ValueError("name must not be empty")
with self._connect() as db:
db.execute(
"""
UPDATE contacts
SET name = ?, email = ?, phone = ?, company = ?, notes = ?
WHERE id = ?
""",
(*values.values(), contact_id),
)
updated = self.get_contact(contact_id)
assert updated is not None
return updated
def delete_contact(self, contact_id: int) -> bool:
with self._connect() as db:
cursor = db.execute(
"DELETE FROM contacts WHERE id = ?", (contact_id,)
)
return cursor.rowcount > 0
Observe lo que falta: importaciones de MCP. Eso es intencional. Las pruebas unitarias para esta clase no necesitan un modelo, cliente de protocolo ni host de IA.
19. Cree el servidor MCP
Ahora crea server.py. El SDK de Python de alto nivel genera esquemas a partir de sugerencias de tipo y descripciones de cadenas de documentos. [5][7]
from __future__ import annotations
import json
from typing import Any
from mcp.server import MCPServer
from mcp.types import ToolAnnotations
from contacts_service import ContactService
service = ContactService("contacts.db")
mcp = MCPServer("Contacts")
@mcp.tool(
annotations=ToolAnnotations(
read_only_hint=True,
open_world_hint=False,
)
)
def list_contacts(limit: int = 50) -> list[dict[str, Any]]:
"""List contacts alphabetically. Read-only. Maximum 200 records."""
return service.list_contacts(limit)
@mcp.tool(
annotations=ToolAnnotations(
read_only_hint=True,
open_world_hint=False,
)
)
def search_contacts(query: str, limit: int = 20) -> list[dict[str, Any]]:
"""Search contacts by partial name, email, phone, or company. Read-only."""
return service.search_contacts(query, limit)
@mcp.tool(
annotations=ToolAnnotations(
read_only_hint=True,
open_world_hint=False,
)
)
def get_contact(contact_id: int) -> dict[str, Any]:
"""Get one contact by numeric ID. Read-only."""
contact = service.get_contact(contact_id)
if contact is None:
raise ValueError(f"contact {contact_id} not found")
return contact
Estas seis herramientas exponen capacidades pequeñas y explícitas. Sus contratos vigentes son:
Herramienta Propósito Entrada principal Salida Errores típicos
límites no válidos
list_contacts Explorar registros limita la matriz de contactos
manipulado/sujetado
Buscar por consulta vacía parcial ->
consulta search_contacts, limitar coincidencias
resultados de campos vacíos
get_contact Obtener registro exacto contact_id objeto de contacto no encontrado
nombre no válido /
create_contact Insertar registro campos de contacto objeto creado
regla de dominio
Herramienta Propósito Entrada principal Salida Errores típicos
Modificar existente no encontrado/no válido
update_contact id + campos opcionales objeto actualizado
campo de registro
política/
eliminar_contacto Eliminar registro contact_id estado de eliminación autorización/no
encontró
En un servidor de producción, reemplace el ValueError genérico con errores deliberados de protocolo/aplicación y asigne fallas de dominio de manera consistente. También haga cumplir la identidad y la autorización dentro de la operación, no solo a través de anotaciones.
20. Agregar recursos de MCP
Agregue dos recursos a server.py:
@mcp.resource("contacts://all")
def contacts_resource() -> str:
"""A JSON snapshot of the first 200 contacts."""
return json.dumps(
service.list_contacts(200),
ensure_ascii=False,
indent=2,
)
@mcp.resource("contacts://{contact_id}")
def contact_resource(contact_id: int) -> str:
"""One contact as JSON, addressed by contact ID."""
contact = service.get_contact(contact_id)
if contact is None:
raise ValueError(f"contact {contact_id} not found")
return json.dumps(contact, ensure_ascii=False, indent=2)
¿Por qué modelarlos como Recursos cuando ya existen las herramientas list_contacts y get_contact? Enseñar la distinción semántica. Un host puede cargar contactos://42 como contexto porque el URI identifica información. La versión de la herramienta es útil cuando el modelo debe decidir activamente buscar algo durante un ciclo de razonamiento.
En un sistema más grande, los recursos se vuelven especialmente naturales para políticas, esquemas, configuración, documentación, archivos u otro material que la aplicación pueda adjuntar al contexto.
21. Agregue un mensaje de MCP
Agregue un mensaje seleccionable por el usuario:
@mcp.prompt()
def prepare_follow_up(contact_id: int, purpose: str = "general follow-up") -> str:
"""Prepare a concise follow-up plan for a contact."""
return f"""
Prepare a professional follow-up for contact ID {contact_id}.
Purpose: {purpose}.
First retrieve the contact. Use any notes as context. Do not invent missing facts.
Redacte el mensaje, pero no envíe nada automáticamente.
""".banda()
Este mensaje se diferencia de una herramienta porque no realiza la acción empresarial. El usuario elige un flujo de trabajo reutilizable que pasa a formar parte de la conversación. El anfitrión/modelo puede entonces decidir si se necesita una herramienta de lectura.
Finish server.py :
if __name__ == "__main__":
mcp.run()
En este punto, el mismo archivo expone herramientas, recursos y un mensaje a través de stdio.
22. Ejecute e inspeccione el servidor MCP localmente
Cree un proyecto e instale el SDK oficial:
mkdir contacts-mcp
cd contacts-mcp
uv init
uv add "mcp[cli]"
Coloque contacts_service.py y server.py en el directorio, luego inicie el inspector de desarrollo:
uv run mcp dev server.py
El SDK oficial de Python utiliza MCP Inspector para el desarrollo interactivo. El comando imprime una URL. El inspector puede enumerar herramientas, recursos y mensajes y le permite invocarlos sin integrar primero un host de producción. Requiere npx /Node.js en la máquina de desarrollo. [5]
Una buena secuencia de prueba es:
1. Llama a create_contact para "Maria Silva".
2. Llame a search_contacts con query="Maria".
3. Leer contactos://todos.
4. Presente el mensaje prepare_follow_up.
5. Llame a update_contact con la nueva ID.
6. Llame a delete_contact y observe la anotación destructiva en los metadatos de la herramienta.
Para una ejecución stdio directa:
uv run mcp run server.py
O simplemente ejecute el archivo si su entorno ya está activado:
python server.py
Importante: con stdio, no escriba texto de depuración en stdout porque stdout lleva mensajes de protocolo. Utilice stderr o un sumidero de registro real.
Para exponer el mismo servidor a través de HTTP, cambie la línea final a:
if __name__ == "__main__":
mcp.run(transport="streamable-http", port=3001)
El SDK sirve al punto final MCP en http://127.0.0.1:3001/mcp de forma predeterminada. [6]
23. Conecte el servidor a clientes reales de IA
La configuración del producto cambia más rápido que el protocolo. Los ejemplos siguientes se compararon con la documentación del proveedor disponible el 23 de agosto de 2026. Considere la disponibilidad del plan de producto y las etiquetas de la interfaz de usuario como cuestiones urgentes.
23.1 Claude Desktop
El SDK de Python puede instalar un servidor local en la configuración de Claude Desktop:
uv run mcp install server.py
En un nivel inferior, la configuración de MCP local comúnmente asigna un nombre de servidor a un comando y argumentos. Una entrada conceptual se parece a:
Claude Desktop actual también proporciona extensiones de escritorio (.mcpb) como una experiencia de empaquetado/distribución para servidores MCP locales. Esta suele ser una mejor ruta de instalación para el usuario final que pedir a los no desarrolladores que editen JSON manualmente. Los controles de administración pueden restringir las extensiones permitidas en espacios de trabajo administrados. [17]
23.2 Claude Code
Claude Code admite servidores stdio locales y HTTP remotos. Un ejemplo local:
claude mcp add --transport stdio contacts -- \
uv run --with "mcp[cli]" mcp run /absolute/path/to/server.py
Un ejemplo remoto:
claude mcp add --transport http contacts https://contacts.example.com/mcp
La configuración de MCP con ámbito de proyecto también puede residir en.mcp.json. El comando claude mcp list ayuda a verificar lo que está configurado. [18]
23.3 ChatGPT
A partir del 23 de agosto de 2026, la experiencia MCP personalizada de ChatGPT se centra en servidores MCP remotos a través de la funcionalidad de desarrollador/aplicación personalizada, con disponibilidad según el plan y los controles del espacio de trabajo. Los documentos de OpenAI ampliaron el soporte completo de MCP en versión beta para espacios de trabajo Business y Enterprise/Edu, mientras que algunas capacidades del modo desarrollador para planes individuales son más limitadas. Los administradores pueden controlar la publicación y los permisos. ChatGPT no trata un proceso stdio local arbitrario en su computadora portátil como un conector remoto directamente accesible; Se requiere un punto final accesible a la red o un mecanismo de desarrollo/túnel seguro compatible. [19]
Conceptualmente, el flujo es:
ChatGPT
|
| aplicación/conector MCP personalizado registrado
v
https://contactos.ejemplo.com/mcp
|
v
Contactos Servidor MCP
Para las herramientas de escritura, espere una política de confirmación y espacio de trabajo más sólida que para las herramientas de estilo de búsqueda/obtención de solo lectura. Las restricciones de los productos evolucionan, así que verifique la configuración actual del Centro de ayuda y del espacio de trabajo antes de diseñar una implementación.
23.4 OpenAI Responses API
La API OpenAI Responses puede exponer servidores MCP remotos a un modelo como herramienta MCP. Un ejemplo mínimo es:
from openai import OpenAI
client = OpenAI()
response = client.responses.create(
model="gpt-5.4",
input="Find Maria Silva's phone number in my contacts.",
tools=[
{
"type": "mcp",
"server_label": "contacts",
"server_url": "https://contacts.example.com/mcp",
"allowed_tools": ["search_contacts", "get_contact"],
"require_approval": "never"
}
],
)
print(response.output_text)
El flujo es:
Su solicitud
|
API/modelo de respuestas de OpenAI
|
Herramienta MCP remota
|
Contactos Servidor MCP
|
SQLite o backend empresarial
Para un servidor con capacidad de escritura, no copie ciegamente la política de aprobación permisiva de solo lectura. Restrinja las herramientas permitidas, requiera la aprobación adecuada para los efectos secundarios y haga que el servidor autorice de forma independiente cada operación. Los datos del servidor MCP son manejados por ese punto final de terceros según sus propias prácticas de retención y seguridad. [20]
23.5 Visual Studio Code / GitHub Copilot
El código VS actual utiliza la configuración de estilo mcp.json. La configuración de un espacio de trabajo puede verse así:
Según el alcance, esto puede residir en.vscode/mcp.json o en la configuración MCP a nivel de usuario. VS Code descubre herramientas del servidor y las pone a disposición de las experiencias de los agentes de acuerdo con la política del usuario/espacio de trabajo. Los entornos administrados de GitHub Copilot pueden aplicar políticas de organización. [21][22]
23.6 Microsoft Copilot Studio
Microsoft Copilot Studio puede incorporar servidores MCP en agentes cuando la orquestación generativa está habilitada. La documentación actual del producto expone específicamente las herramientas y recursos de MCP; No se debe suponer que el soporte del producto equivale a cada primitiva o extensión de protocolo. Los cambios del lado del servidor se pueden reflejar dinámicamente sin reconstruir un esquema de acción propietario para cada herramienta. [23]
23.7 Gemini CLI y otros hosts
Gemini CLI admite entradas del servidor MCP en settings.json. Un ejemplo local es conceptualmente:
También se admiten configuraciones HTTP remotas. Otros hosts MCP ampliamente utilizados incluyen Cursor y numerosos marcos de agentes. La lección no es la lista de productos; es que el mismo modelo de capacidad del lado del servidor se puede reutilizar en hosts con diferentes capas de configuración y políticas. [24]
24. Pruebe el servidor de contactos mediante lenguaje natural
El protocolo se vuelve tangible cuando sigues la solicitud de un usuario de principio a fin.
Ejemplo A: "Buscar el número de teléfono de John Smith".
Aviso de usuario
-> El modelo decide que se necesita una búsqueda
-> Herramienta seleccionada: search_contacts
-> Argumentos: {"consulta": "John Smith", "límite": 20}
-> El cliente MCP envía herramientas/llamada
-> Contactos MCP Server llama a ContactService
-> SQLite devuelve filas coincidentes
-> El resultado de la herramienta devuelve datos de contacto estructurados
-> El modelo responde con el número de teléfono, citando ambigüedad si coinciden varios Johns
Ejemplo B: "Agregar María Silva a mis contactos. Su correo electrónico es maria@example.com".
El modelo debe elegir create_contact con argumentos estructurados:
El anfitrión puede solicitar confirmación porque se trata de una escritura. El servidor aún valida la entrada y la autorización de la persona que llama.
Ejemplo C: "¿Qué contactos funcionan para Contoso?"
Un modelo puede llamar:
{"query": "Contoso", "limit": 20}
El servidor devuelve coincidencias cuya empresa/nombre/correo electrónico/teléfono contiene el término. Un servidor de producción más sofisticado podría exponer search_contacts(company=...) para que la semántica sea explícita.
Ejemplo D: "Cambiar el número de teléfono de John".
Esta solicitud está incompleta si existe más de un John. Un agente seguro debe buscar primero, eliminar la ambigüedad si es necesario y luego llamar a update_contact con el ID seleccionado. La orquestación de herramientas no se trata simplemente de invocación; se trata de gestionar la incertidumbre antes de los efectos secundarios.
Ejemplo E: "Eliminar el contacto de prueba que creé anteriormente".
Esto combina la memoria de la conversación con una acción destructiva. El anfitrión debe identificar el registro previsto y confirmar si la política lo requiere. El servidor debe rechazar la eliminación si la persona que llama no está autorizada, incluso si el modelo tiene confianza.
25. Implementación de un servidor MCP remoto
Un servidor remoto es la misma capa de capacidad ubicada detrás de la infraestructura HTTP de producción. No necesitas una arquitectura exótica.
Internet / Red Corporativa
|
HTTPS
|
Proxy inverso/puerta de enlace API
|
+------+------+
| |
Instancia MCP Instancia MCP
| |
+------+------+
|
Servicio de contacto/API
|
Base de datos
Para el ejemplo de Python, puede exponer una aplicación Starlette/ASGI desde el SDK y ejecutarla en una infraestructura ASGI estándar, o utilizar el ejecutor Streamable HTTP integrado del SDK. [6]
Una lista de verificación de producción incluye:
Utilice un dominio real y un certificado TLS.
Coloque los secretos en un administrador de secretos o en un entorno protegido, no en el control de fuentes.
Autenticar clientes y autorizar acciones.
Utilice un proxy inverso/puerta de enlace API cuando mejore la política, la limitación de velocidad, el registro o el enrutamiento.
Utilice contenedores si eso se adapta a su plataforma; no lo coloque en contenedores simplemente porque MCP es nuevo.
Escale horizontalmente donde la carga de trabajo lo requiera. El núcleo 2026 sin estado hace que el enrutamiento por turnos sea natural.
Centralice registros, métricas, seguimientos y eventos de auditoría.
Aplique tiempos de espera y tamaños de respuesta acotados.
El diseño debería seguir siendo aburrido en el mejor sentido: MCP es un protocolo de aplicación que se ejecuta en prácticas de infraestructura que ya comprende.
26. Autenticación y autorización de MCP
El stdio local y el HTTP remoto tienen diferentes modelos de amenaza. Un servidor local puede heredar permisos de identidad y sistema de archivos del entorno del proceso. Se puede acceder a un servidor remoto a través de una red y necesita decisiones explícitas de identidad, token, alcance y autorización.
El modelo de autorización HTTP de MCP se alinea con las convenciones modernas de OAuth. En un flujo típico de recursos protegidos:
Cliente MCP
|
| 1. solicitar un punto final MCP protegido
v
Servidor de recursos MCP
|
| 2. 401 + información de descubrimiento
v
Metadatos de recursos protegidos (RFC 9728)
|
| apunta a los servidores de autorización
v
Servidor de autorización
|
| 3. autorizaciones de usuario/cliente, código + flujo PKCE
| 4. solicitud de token, validar emisor, vincular recurso
v
Token de acceso
|
| 5. Autorización: Portador <token>
v
Servidor de recursos MCP
El servidor puede publicar metadatos de recursos protegidos en un punto final conocido. El SDK de Python actual documenta una ruta como /.well-known/oauth-protected-resource/mcp, que identifica el recurso MCP protegido, los servidores de autorización, los ámbitos admitidos y el método de token de portador. [9]
26.1 Postura de seguridad estilo OAuth 2.1
Utilice flujos de código de autorización con PKCE para clientes interactivos, tokens de acceso de corta duración, TLS, validación de redireccionamiento exacto y enlace de alcance/recursos. El servidor debe tratar el token de acceso como evidencia de autoridad delegada, no como un permiso general para hacerlo todo.
26.2 Indicadores de recursos
Un token debe estar destinado al recurso MCP al que se presenta. Los indicadores de recursos reducen la confusión de tokens al vincular la autorización a un recurso protegido particular en lugar de crear un token portador multiuso.
26.3 Metadatos de recursos protegidos
En lugar de requerir conocimiento fuera de banda de cada punto final de autorización, el recurso MCP puede publicar metadatos legibles por máquina que le indiquen al cliente dónde ocurre la autorización y qué alcances existen.
26.4 Validación del emisor
La revisión del 28 de julio de 2026 requiere un manejo más estricto del emisor del servidor de autorización: los clientes validan el valor de emisión según RFC 9207 antes de canjear un código de autorización. Esto mitiga los ataques de confusión del servidor de autorización. [2]
26.5 CIMD reemplaza a DCR como dirección de viaje
El registro dinámico de clientes (DCR) se utilizó ampliamente en ejemplos anteriores de MCP OAuth. La revisión del 28 de julio de 2026 desaprueba DCR en favor de los documentos de metadatos de ID de cliente (CIMD). Con CIMD, un cliente publica metadatos en una URL HTTPS estable y puede usar esa URL como su identificador de cliente cuando el servidor de autorización admite el mecanismo. DCR sigue siendo una ruta de compatibilidad con versiones anteriores para servidores que no han migrado. [2][10]
26.6 La autorización sigue siendo específica de la aplicación
OAuth responde "¿quién/qué llama y qué alcances delegados se otorgaron?" Su servicio comercial aún debe responder preguntas como:
¿Puede este empleado leer el contacto 123?
¿Esta cuenta de servicio puede eliminar contactos?
¿Se le permite a este inquilino ver el registro de esta empresa?
¿Contactos:escribir incluye eliminación destructiva o solo actualización?
MCP no reemplaza la autorización de dominio.
27. Seguridad del MCP
La seguridad en producción combina identidad, privilegio mínimo, validación, aislamiento, aprobaciones y observabilidad.
Un servidor MCP es parte del límite de seguridad de su aplicación porque puede exponer tanto datos confidenciales como acciones poderosas. Trátelo como una API más una capa semántica orientada al agente.
27.1 Inyección de prompts e inyección indirecta de prompts
Un modelo puede consumir texto que no es de confianza de documentos, sitios web, correos electrónicos, rastreadores de problemas o recursos de MCP. Ese texto puede contener instrucciones que intentan anular la intención del usuario o provocar llamadas a herramientas. El ataque se vuelve indirecto cuando la instrucción hostil se encuentra dentro del contenido recuperado en lugar de en el mensaje del usuario.
Las defensas incluyen separar el contenido que no es de confianza de las instrucciones privilegiadas, minimizar las herramientas de escritura disponibles, exigir confirmación para acciones sensibles, restringir las herramientas permitidas por flujo de trabajo y validar la política del lado del servidor independientemente del razonamiento del modelo.
27.2 Servidores maliciosos y envenenamiento de herramientas
Un servidor controla las descripciones de sus herramientas y el contenido devuelto. Un servidor malicioso podría anunciar descripciones engañosas, devolver instrucciones dirigidas al modelo o intentar inducir llamadas a otras capacidades. Instale o conéctese únicamente a servidores de fuentes en las que confíe. Trate la instalación del servidor comunitario como una instalación de la cadena de suministro de software, no como agregar un sitio web a favoritos.
27.3 Permisos excesivos
No otorgue permiso al servidor MCP de contactos para todo el directorio corporativo si el caso de uso requiere solo los registros de un equipo de ventas. Prefiera privilegios mínimos en cada capa: alcances de OAuth, concesiones de bases de datos, cuentas de servicio, listas de herramientas permitidas, acceso al sistema de archivos y salida de la red.
27.4 Exfiltración de datos y fuga de credenciales
Una herramienta que puede leer secretos más una herramienta que puede enviar solicitudes HTTP arbitrarias es una composición peligrosa. No se deben devolver secretos al modelo. Proteja el acceso a la red saliente cuando corresponda. Redactar credenciales de registros y resultados de herramientas. Nunca almacene tokens de acceso en descripciones de herramientas, mensajes o configuraciones controladas por fuente.
27.5 Llamadas destructivas
search_contacts tiene un riesgo relativamente bajo. eliminar_contacto no lo es. Utilice controles en capas:
marcar el comportamiento destructivo en los metadatos para que los clientes puedan presentar una experiencia de usuario más segura;
requerir aprobación humana cuando la política lo requiera;
autorizar la eliminación del lado del servidor;
registrar quién eliminó qué y por qué;
utilizar ventanas de eliminación temporal o recuperación cuando el dominio las admita;
operaciones destructivas con límite de velocidad.
27.6 Problema del agente confundido (confused deputy)
Un servidor puede convertirse en un sustituto confundido cuando tiene credenciales poderosas y realiza una acción para una persona que llama que no debería tener esa autoridad. Vincular la identidad de la persona que llama a las comprobaciones de autorización; no permita que la cuenta de servicio amplia del servidor se convierta en un permiso implícito.
27.7 SSRF y herramientas de mundo abierto
Las herramientas que obtienen URL arbitrarias pueden crear riesgos de falsificación de solicitudes del lado del servidor (SSRF). Restrinja esquemas, destinos, rangos de direcciones privadas, redirecciones y comportamiento de DNS. Si la herramienta no necesita Internet abierto, cierre el acceso saliente de forma predeterminada.
27.8 Validación de entradas y salidas
Las entradas de un modelo no son de confianza. Es posible que tampoco se pueda confiar en las salidas de los sistemas ascendentes. Validar ambas direcciones. Aplique límites de tamaño de salida para evitar que una llamada MCP descargue cientos de megabytes en un contexto modelo.
27.9 Pila de control práctica
Una línea base de seguridad de MCP de producción debe incluir:
autenticación y autorización explícita;
ámbitos e identidades de servicio con privilegios mínimos;
registro de servidores aprobados o lista de permitidos;
listas permitidas a nivel de herramienta;
confirmación de escrituras de alto impacto;
sandboxing para ejecución local/no confiable cuando sea posible;
gestión secreta;
validación de solicitudes y respuestas;
límites de tarifas, cuotas y tiempos de espera;
registros de auditoría;
dependencia y escaneo de la cadena de suministro;
Monitoreo de patrones anómalos de invocación de herramientas.
28. MCP en entornos empresariales
MCP se vuelve especialmente interesante cuando una organización tiene muchos sistemas existentes y muchas experiencias de IA.
Asistente de IA empresarial
|
Capa MCP
|
+------+------+------+------+
| | | | |
CRM API GW DB Docs DevOps
MCP MCP MCP MCP MCP
Un servidor CRM puede exponer la búsqueda de cuentas. Un servidor API Gateway puede exponer el catálogo de API y los metadatos operativos. Un servidor de base de datos puede exponer consultas analíticas limitadas. Un servidor de documentación puede exponer estándares internos. Un servidor DevOps puede exponer operaciones de compilación o implementación con estrictos controles de aprobación.
Las empresas deben evitar un ecosistema del salvaje oeste donde cada empleado ejecuta servidores arbitrarios con credenciales de producción. Los patrones de gobernanza útiles incluyen:
registro central MCP de servidores aprobados;
editores verificados y fijación de versiones;
integración del proveedor de identidad;
control de acceso basado en roles (RBAC);
taxonomía de alcance estándar de OAuth;
políticas de red y controles de salida;
listas de herramientas permitidas por persona/flujo de trabajo;
retención de auditoría;
propiedad de dependencias y SLA de parches;
Pruebas de compatibilidad entre versiones de protocolo.
MCP también introdujo una extensión de Autorización administrada empresarial (EMA) en 2026. EMA tiene como objetivo el acceso al servidor con identidad integrada y aprovisionamiento centralizado para que los usuarios empresariales puedan recibir conexiones MCP aprobadas sin repetir la configuración ad-hoc de OAuth para cada servidor. Trátelo como una extensión que requiere soporte de ecosistema compatible, no como parte del núcleo mínimo. [16]
29. Puertas de enlace MCP y API
Las organizaciones con una gestión de API madura no deberían evitarla simplemente porque la persona que llama es un agente de IA.
Un patrón empresarial común es:
Agente de IA
|
Cliente MCP
|
Servidor MCP empresarial
|
Puerta de enlace API
|
API internas
|
Microservicios
La capa MCP traduce las herramientas orientadas a la IA en operaciones API existentes. La puerta de enlace API continúa brindando autenticación, autorización, limitación de velocidad, enrutamiento, protección contra amenazas, análisis y aplicación de políticas de API.
El protocolo 2026-07-28 mejora esta adaptación para las puertas de enlace. Las solicitudes HTTP transmitibles pueden exponer información de método/herramienta a través de encabezados Mcp-Method y Mcp-Name, lo que permite tomar decisiones de enrutamiento o medición sin una inspección profunda de los cuerpos de solicitud JSON. [2]
Esta arquitectura es útil cuando la organización desea un puente gobernado entre las capacidades del agente y su conjunto de API existente. También evita que el servidor MCP se convierta en una plataforma de integración en la sombra que duplique silenciosamente todo lo que la puerta de enlace ya hace bien.
30. Observabilidad y operaciones.
Un servidor MCP de producción necesita observabilidad del servicio ordinario además de semántica a nivel de herramienta.
Capture métricas como:
recuento de solicitudes y tasa de error por método MCP;
recuento de invocaciones de herramientas por nombre de herramienta;
latencia de herramienta p50/p95/p99;
latencia de base de datos/API ascendente;
fallas de autorización;
eventos de límite de tasa;
tasas de cancelación y fracaso de tareas;
tamaños de respuesta y contribución del contexto;
recuentos de reintentos y tasas de tiempo de espera.
Para el seguimiento, propague un identificador de correlación/rastreo desde la solicitud HTTP a través del servidor MCP hasta las API posteriores. Una llamada a una herramienta que afecte CRM, facturación y una base de datos debe poder rastrearse como una sola operación.
Los registros de auditoría para acciones de escritura deben responder: quién inició la operación, a través de qué host/cliente, qué herramienta se ejecutó, qué registro de destino cambió, qué política lo permitió y cuál fue el resultado.
De forma predeterminada, no registre tokens de acceso, contraseñas, encabezados secretos completos ni registros confidenciales completos. El registro debería ser útil sin convertirse en una violación de datos secundaria.
Para servidores stdio locales, recuerde que stdout pertenece al protocolo. Envíe registros operativos a stderr o a un receptor de archivos/telemetría.
31. Errores comunes en el desarrollo de MCP
31.1 Crear herramientas demasiado genéricas
Manage_everything(action, payload) hace que el comportamiento del modelo sea más difícil de predecir y que los permisos sean más difíciles de alcanzar. Divida las responsabilidades donde el dominio lo admita.
31.2 Exponer demasiadas herramientas
Más herramientas pueden significar más confusión, contexto más amplio y peor selección de herramientas. Exponga las capacidades necesarias para el flujo de trabajo actual, no para toda la empresa.
31.3 Escribir descripciones vagas
Las descripciones son parte de la interfaz del modelo. Indique el propósito, los límites, los efectos secundarios y las condiciones previas importantes.
31.4 Volviendo a un contexto enorme
No devuelva una tabla de base de datos completa porque el modelo hizo una pregunta. Pagina, filtra, resume de forma determinista y expone recursos con lecturas limitadas.
31.5 Poner secretos en archivos de configuración
Utilice gestión de secretos específica del entorno. La configuración del desarrollador local debe hacer referencia a secretos en lugar de incorporar credenciales de producción de larga duración.
31.6 Conceder acceso de escritura cuando la lectura es suficiente
Separe los servidores/herramientas de solo lectura de la capacidad de mutación cuando sea práctico. El privilegio mínimo reduce tanto los accidentes como el impacto de la inyección.
31.7 Confiar en servidores comunitarios arbitrarios
Audite la fuente, la procedencia del paquete, las dependencias, los permisos y el comportamiento de la red. Un servidor MCP local es un código ejecutable.
31.8 Combinación de código de protocolo con lógica empresarial
Mantenga MCP como adaptador. Esto mejora las pruebas, la portabilidad y la revisión de seguridad.
31.9 Ignorar errores de herramientas
Devuelve errores deliberados con semántica estable. El host/modelo debe distinguir entre no encontrado, validación, autorización, conflicto, falla ascendente transitoria y falla permanente.
31.10 Confiar en argumentos generados por modelos
Nunca asuma que un esquema estructurado hace que los datos sean seguros. Valide las reglas de autorización y dominio después del análisis.
32. Gestión del contexto y rendimiento del MCP
El diseño del servidor MCP es en parte diseño de sistemas distribuidos y en parte diseño de contexto LLM.
Cada descripción de herramienta que ve el modelo consume tokens. Los esquemas JSON grandes consumen más. Los resultados de grandes recursos consumen contexto. Las llamadas de red añaden latencia. Las cadenas de herramientas multiplican los viajes de ida y vuelta.
Esto conduce a varios principios de ingeniería:
Mantenga los catálogos de herramientas relevantes para el usuario/flujo de trabajo actual.
Prefiera descripciones concisas que no sean ambiguas.
Esquemas vinculados y tamaños de respuesta.
Paginar resultados de búsqueda.
Devuelve los campos estructurados que el modelo realmente necesita.
Resultados de descubrimiento/lista de caché de acuerdo con las sugerencias del servidor donde el host lo admite.
Evite colocar cargas útiles binarias o textuales enormes directamente en el contexto del modelo.
Mida la calidad de la selección de herramientas a medida que crece el catálogo.
Las sugerencias de caché del protocolo 2026 en las respuestas de lista/lectura están diseñadas en parte para reducir el trabajo de descubrimiento repetido y estabilizar el almacenamiento en caché de avisos ascendentes. [2]
Un antipatrón común es exponer 300 herramientas casi superpuestas a cada conversación. El protocolo técnicamente puede transportarlos; eso no significa que el modelo razonará sobre ellos de manera eficiente.
33. Cuando MCP tiene sentido
MCP es una buena opción cuando la reutilización y la interoperabilidad son requisitos reales. Los ejemplos incluyen:
un asistente interno de IA que necesita acceso a CRM, documentos, tickets y API;
una herramienta de desarrollo que debería funcionar en múltiples IDE/agentes compatibles con MCP;
un asistente de base de datos cuyas capacidades de consulta deberían ser reutilizables entre hosts;
una plataforma de agentes empresariales con proveedores de capacidades gobernados;
un producto SaaS que quiere exponer capacidades amigables para los agentes a múltiples ecosistemas de IA;
una herramienta de desarrollo local que se beneficia del empaquetado estándar y el descubrimiento automático.
Una pregunta de decisión útil es: ¿Esta capacidad será consumida por más de un host de IA o quiero tener la opción de cambiar de host sin reconstruir el contrato de integración? En caso afirmativo, MCP merece una seria consideración.
34. Cuando MCP puede ser innecesario
MCP no es una capa obligatoria para cada integración de modelo.
Una llamada REST directa puede ser más sencilla cuando su aplicación ya sabe exactamente a qué punto final llamar y no se necesita una selección controlada por el modelo. Las llamadas a funciones tradicionales pueden ser suficientes cuando una aplicación posee cinco funciones privadas y no se requiere interoperabilidad. Un SDK de proveedor puede ser ideal cuando necesita funciones exclusivas de ese proveedor. Un pequeño adaptador interno puede resultar más económico que operar un servidor MCP reutilizable.
Preguntar:
1. ¿Es útil el descubrimiento o ya conozco esa operación? 2. ¿Varios hosts consumirán esta capacidad? 3. ¿Necesito recursos o indicaciones, o solo un esquema de función? 4. ¿La ejecución de otro servidor/proceso mejora la modularidad lo suficiente como para justificar la superficie operativa? 5. ¿El host de destino es realmente compatible con las funciones de MCP que necesito?
Utilice MCP cuando reduzca la complejidad a nivel del sistema, no porque esté de moda.
35. El futuro de MCP
Los hechos actuales y la dirección futura deben separarse cuidadosamente.
Hechos actuales en 2026: MCP tiene un núcleo sin estado, transportes HTTP stdio y Streamable, herramientas/recursos/indicaciones, un marco de extensiones, tareas como una extensión, aplicaciones MCP como una extensión para la interfaz de usuario interactiva proporcionada por el servidor y trabajo de autorización empresarial como EMA. Los principales proveedores de IA y herramientas de desarrollo participan en el ecosistema. [2][14]
Dirección de la hoja de ruta: la hoja de ruta de agosto de 2026 de los mantenedores de MCP destaca el trabajo continuo en primitivas de mensajería agente, refuerzo del transporte nativo HTTP, identidad del agente y seguridad empresarial, primitivas más ricas y experiencia de SDK/desarrollador. Una hoja de ruta es una intención, no una garantía de que una característica ya esté estandarizada o enviada. [25]
Un efecto probable a largo plazo es organizacional: las aplicaciones pueden publicar cada vez más superficies de capacidades orientadas a los agentes junto con las API tradicionales. Las API siguen siendo el contrato de software; MCP puede convertirse en una capa estandarizada de consumo de agentes que describe lo que una IA puede descubrir y hacer.
MCP Apps también apunta hacia interacciones más ricas que las llamadas a herramientas invisibles. Un servidor puede asociar una herramienta con una interfaz de usuario HTML en espacio aislado que los hosts compatibles pueden representar. Eso extiende MCP de "llamar funciones" a "llevar capacidad interactiva al host", manteniendo al mismo tiempo el soporte de UI opcional y dependiente del host. [2]
La idea más importante no es que MCP sea el único protocolo de agente para siempre. La cuestión es que los ecosistemas de IA se vuelven más útiles cuando las herramientas no quedan atrapadas detrás del formato de integración personalizado de un proveedor.
36. Modelo mental final
Si recuerdas solo una oración, usa esta:
Las API exponen capacidades al software; MCP expone capacidades de forma estandarizada a aplicaciones y agentes de IA.
Es una simplificación excesiva porque los servidores MCP a menudo llaman a las API subyacentes, porque las llamadas a funciones aún se pueden usar dentro de un host y porque los recursos/indicaciones/extensiones van más allá de una simple fachada de API. Pero es un punto de partida útil.
Entonces recuerda las piezas:
Anfitrión: la aplicación de IA y la experiencia del usuario.
Cliente: el componente de protocolo dentro del host que se comunica con un servidor.
Servidor: el proveedor de capacidad.
Herramientas: operaciones invocables por modelo.
Recursos: contexto direccionable que la aplicación puede leer.
Mensajes: plantillas de mensajes reutilizables seleccionadas por el usuario.
Transporte: stdio local; HTTP transmitible de forma remota.
Autorización: identidad y acceso delegado para servidores remotos protegidos; todavía respaldado por la autorización de dominio.
Extensiones: capacidades opcionales como Tareas, Aplicaciones MCP y autorización administrada por la empresa.
Y para la generación de protocolo actual, recuerde una cosa más: el MCP moderno no tiene estado en esencia. No cree una nueva arquitectura 2026 en torno al antiguo ciclo de vida obligatorio de inicialización/sesión.
37. Conclusión
Comenzamos con una empresa que tenía muchas aplicaciones de IA y muchos sistemas. Sin un límite de integración compartido, cada combinación puede convertirse en un adaptador personalizado con sus propios esquemas, autenticación, descubrimiento y ciclo de vida.
MCP cambia la unidad de integración. Un CRM, una base de datos, una plataforma de desarrollador, un sistema de contacto o una API interna pueden exponer un servidor MCP. Los hosts compatibles pueden descubrir sus herramientas, leer sus recursos, utilizar sus indicaciones e invocar capacidades a través de un protocolo estándar. Eso no elimina la configuración específica del producto o la política de seguridad, pero reduce la necesidad de reinventar el contrato básico de host a capacidad.
También ha visto que MCP es más que "herramientas de llamadas de LLM". Su arquitectura separa Host, Cliente y Servidor. JSON-RPC proporciona el sobre del mensaje. Las herramientas representan operaciones, los recursos representan el contexto direccionable y las indicaciones representan flujos de trabajo de usuario reutilizables. stdio se adapta a servidores locales; Streamable HTTP se adapta a los sistemas implementados. La autorización orientada a OAuth protege los servidores remotos. Las extensiones manejan preocupaciones como tareas de larga duración y una interfaz de usuario más rica. Y las implementaciones maduras todavía dependen de puertas de enlace API, identidad, privilegios mínimos, observabilidad, validación y aprobación humana.
Lo más importante es que el ejemplo de Contactos demuestra por qué existen las capas. El servicio empresarial no conoce MCP. No es necesario que el servidor MCP sea propietario del modelo de base de datos. El anfitrión no necesita entender SQLite. El modelo sólo ve capacidades descritas en el nivel semántico correcto.
El potencial de MCP es significativo precisamente porque no intenta reemplazar todas las capas. Es un límite estándar entre las aplicaciones de IA y las capacidades externas que necesitan. Sus limitaciones son igualmente importantes: la interoperabilidad varía, la selección de herramientas modelo puede fallar, las características del protocolo evolucionan y exponer acciones a los agentes amplía la superficie de seguridad.
El futuro más interesante puede ser aquel en el que las aplicaciones publiquen dos interfaces intencionales: API para la integración determinista de software y capacidades estandarizadas de cara al agente para sistemas de inteligencia artificial. Si ese futuro llega de manera amplia, la pregunta ya no será sólo “¿Esta aplicación tiene API?” También será: "¿Qué puede descubrir y hacer aquí de forma segura un agente de IA autorizado?"
38. Referencias y lecturas adicionales
Las fuentes a continuación priorizan las especificaciones oficiales, la documentación del proyecto, la documentación del proveedor y los anuncios de fundaciones. Las páginas específicas de productos cambian con frecuencia; verifíquelos nuevamente antes de la implementación en producción.
1. Anthropic. "Presentación del Model Context Protocol". 25 de noviembre de 2024. https://www.anthropic.com/news/model-context-protocol 2. Mantenedores del Model Context Protocol. "La especificación del 28 de julio de 2026". 28 de julio de 2026. https://blog.modelcontextprotocol.io/posts/2026-07-28/ 3. Mantenedores del Model Context Protocol. "Candidato de versión de especificación MCP del 28 de julio de 2026". 21 de mayo de 2026. https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/ 4. Extensión de tareas de MCP. "Descripción general" y extensión de tareas SEP-2663. https://tasks.extensions.modelcontextprotocol.io/ 5. MCP Python SDK v2. Primeros pasos/primeros pasos. https://py.sdk.modelcontextprotocol.io/ 6. MCP Python SDK v2. Ejecutando su servidor/transportes. https://py.sdk.modelcontextprotocol.io/run/ 7. MCP Python SDK v2. Herramientas y anotaciones de herramientas. https://py.sdk.modelcontextprotocol.io/servers/tools/ 8. MCP Python SDK v2. Recursos e indicaciones. https://py.sdk.modelcontextprotocol.io/servers/resources/ y https://py.sdk.modelcontextprotocol.io/servers/prompts/ 9. MCP Python SDK v2. Autorización y metadatos de recursos protegidos. https://py.sdk.modelcontextprotocol.io/run/authorization/ 10. MCP Python SDK v2. Clientes OAuth y documentos de metadatos de ID de cliente. https://py.sdk.modelcontextprotocol.io/client/oauth-clients/ 11. Especificación del Model Context Protocol. Documentación actual de especificaciones y protocolos. https://modelcontextprotocol.io/ 12. SDK de MCP Python. Documentación del servidor de bajo nivel. https://py.sdk.modelcontextprotocol.io/v2/advanced/low-level-server/ 13. MCP TypeScript SDK v2. Migración/soporte para 2026-07-28. https://ts.sdk.modelcontextprotocol.io/v2/ 14. Fundación Linux. Anuncio de la Agentic AI Foundation (AAIF), 9 de diciembre de 2025. https://www.linuxfoundation.org/press/linux-foundation-launches-the-agentic-ai-foundation 15. Anthropic. Anuncio de gobernanza/contribución del MCP para AAIF. Diciembre de 2025. https://www.anthropic.com/news/model-context-protocol-joins-aaif 16. Blog del Model Context Protocol. "Autorización administrada por la empresa: OAuth sin intervención para MCP". 18 de junio de 2026. https://blog.modelcontextprotocol.io/ 17. Centro de ayuda Anthropic. Servidores MCP locales y extensiones de escritorio para Claude Desktop. https://support.anthropic.com/ 18. Documentación del Claude Code. Conecte Claude Code a herramientas a través de MCP. https://docs.anthropic.com/en/docs/claude-code/mcp 19. Centro de ayuda de OpenAI. "Modo desarrollador y aplicaciones MCP en ChatGPT (Beta)". https://help.openai.com/en/articles/12584461-developer-mode-and-mcp-apps-in-chatgpt-beta 20. Documentación de la API de OpenAI. OpenAI Responses API y herramientas MCP. https://developers.openai.com/api/reference/ y https://developers.openai.com/ 21. Visual Studio Code. Servidores MCP en VS Code. https://code.visualstudio.com/docs/copilot/chat/mcp-servers 22. Documentos de GitHub. Ampliación de GitHub Copilot con MCP. https://docs.github.com/en/copilot/customizing-copilot/extending-copilot-chat-with-mcp 23. Microsoft Learn. Model Context Protocol en Microsoft Copilot Studio. https://learn.microsoft.com/en-us/microsoft-copilot-studio/agent-extend-action-mcp 24. Documentación de Gemini CLI. Configuración del servidor MCP. https://github.com/google-gemini/gemini-cli/blob/main/docs/tools/mcp-server.md 25. Blog de Model Context Protocol. Hoja de ruta 2026, publicada el 22 de agosto de 2026. https://blog.modelcontextprotocol.io/
Apéndice A: referencia rápida actual frente a heredada
Recomendación actual (2026-
Tema Legacy/nota de compatibilidad
07-28)
Revisiones anteriores utilizadas
Estado central Solicitud/respuesta sin estado
estado de inicialización/sesión
inicializar/inicializado común en
Inicialización No es obligatorio inicializar el protocolo de enlace
tutoriales 2025
Negociación de capacidad más antigua
Descubrimiento de servidor Servidor/descubrimiento opcional
sucedió en la inicialización
Recomendación actual (2026-
Tema Legacy/nota de compatibilidad
07-28)
Estación de transporte local Aún vigente
Transporte remoto Streamable HTTP HTTP+SSE obsoleto
io.modelcontextprotocol/tasks Las tareas centrales experimentales existían en
Tareas
extensión 2025-11-25
Roots en desuso permanece durante la ventana de migración
Prefiere API directas de proveedor de modelos
Muestreo en desuso
para nuevos diseños
Primitivo de registro En desuso Prefiero registros/telemetría estándar
Se prefiere CIMD cuando
DCR Dirección obsoleta
apoyado
MCP Apps Extensión oficial El soporte del host varía
Autorización administrada empresarial Extensión oficial El soporte del ecosistema varía
Apéndice B: Lista de verificación de preparación para la producción
Protocolo y compatibilidad
☐ Fije y documente la revisión del protocolo MCP que admite.
☐ Pruebe con al menos dos hosts previstos cuando el objetivo sea la interoperabilidad.
☐ Separe los requisitos básicos de las extensiones opcionales.
☐ No dependa de primitivas obsoletas para un nuevo diseño sin un motivo de migración.
Diseño de herramientas
☐ Las herramientas tienen nombres explícitos y responsabilidades limitadas.
☐ Las descripciones indican los efectos secundarios y los límites importantes.
☐ Las entradas utilizan esquemas acotados y validación del lado del servidor.
☐ Los resultados están estructurados y tienen un tamaño limitado.
☐ Las capacidades de lectura y escritura son separables.
Seguridad
☐ La autenticación y la autorización de dominio se aplican en el lado del servidor.
☐ Los ámbitos de OAuth siguen el privilegio mínimo.
☐ Las operaciones destructivas tienen controles más estrictos.
☐ Los secretos nunca ingresan a resultados visibles del modelo ni a registros ordinarios.
☐ El acceso a la red saliente está restringido cuando el acceso abierto a Internet no es necesario.
☐ Los servidores MCP de terceros se revisan como dependencias de software ejecutables.
Operaciones
☐ Las llamadas a herramientas tienen métricas de latencia/error.
☐ Las escrituras confidenciales producen eventos de auditoría.
☐ Se definen tiempos de espera, reintentos y límites de velocidad.
☐ Los ID de seguimiento se propagan a las API posteriores.
☐ Los resultados grandes están paginados o delimitados.
☐ Los procedimientos de actualización cubren las revisiones del SDK y del protocolo.
