Ya tienes una API. ¿Necesitas un servidor MCP?

En algún momento de este año, alguien en tu equipo directivo preguntó si hace falta un servidor MCP. Es una pregunta razonable. Un servidor MCP es lo que le permite a un asistente de IA como Claude o ChatGPT encontrar las acciones de tu producto y ejecutarlas en nombre de un usuario. Para diciembre de 2025, Anthropic reportaba más de 10,000 servidores MCP públicos activos y había donado el Model Context Protocol a la Agentic AI Foundation, que cofundó con Block y OpenAI como iniciativa de la Linux Foundation.

Si construyes un servidor MCP, trátalo como lo que es: una segunda puerta de entrada a tu producto, usada por un cliente de IA que lee tus descripciones y decide por su cuenta qué llamar.

¿Qué es un servidor MCP y en qué se diferencia de tu API?

Tu API se diseñó para developers. Una persona lee la documentación, escribe el código que llama a tus endpoints y lo despliega. Ese código hace exactamente las llamadas que el developer programó.

Un servidor MCP se diseña para modelos. Publica una lista de herramientas, cada una con nombre, descripción y un esquema de entrada, y un modelo de IA decide en tiempo de ejecución qué herramienta llamar y con qué argumentos. El backend puede ser el mismo. El consumidor es otro por completo: algo que razona a partir de tus descripciones, no de tu documentación, y que actúa en nombre de un usuario que no está mirando cada llamada.

La mayoría de las APIs no se pensaron para ese consumidor. El reporte State of the API 2025 de Postman, una encuesta a más de 5,700 developers, encontró que solo el 24% diseña APIs pensando activamente en agentes de IA.

¿De verdad necesitas un servidor MCP?

Depende de quién sea el agente.

• Tus propios agentes. Si la única IA que llama a tus sistemas es un asistente que construyó tu equipo, quizá no necesites MCP. Llamar herramientas directamente desde tu propio agente de IA funciona bien. MCP empieza a valer la pena cuando varios agentes o varios clientes de IA necesitan las mismas herramientas.
• Los agentes de tus clientes. Si tus compradores ya trabajan dentro de Claude, ChatGPT o Copilot y quieren operar tu producto desde ahí, un servidor MCP pasa a ser parte de tu producto, en la misma categoría que tu API pública o tu integración con Zapier. Aquí es donde más sentido tiene.
• Nadie todavía. Entonces no lo construyas. Mantén tu API limpia y documentada, porque sobre eso se monta después un buen servidor MCP.

¿Conviene convertir cada endpoint en una herramienta MCP?

La tentación es generar una herramienta por endpoint y dar el trabajo por terminado. Muchos equipos empiezan por ahí: en una encuesta a quienes construyen servidores MCP, publicada por la plataforma de APIs Zuplo en enero de 2026, el 58% dijo que está envolviendo APIs existentes. La guía de ingeniería de la propia Anthropic lo dice sin rodeos: uno de los errores comunes que han observado son las herramientas que solo envuelven funcionalidad o endpoints de API que ya existen.

Las herramientas calcadas de tus endpoints le pasan al modelo tu trabajo de integración. Para responder "¿qué facturas de clientes enterprise están vencidas?" tiene que listar clientes, filtrar, paginar facturas y cruzar resultados: varias llamadas donde debería bastar una. Las herramientas orientadas a tareas se parecen a cómo la gente describe el trabajo: find_overdue_invoices, summarize_account, draft_refund. Cada definición de herramienta también ocupa contexto del modelo, así que un servidor con 80 herramientas que apenas envuelven un endpoint es más lento y más caro que uno con 8 bien diseñadas.

¿Cómo proteger un servidor MCP?

La misma encuesta de Zuplo encontró que la seguridad y el control de acceso son el principal desafío, señalado por el 50% de quienes construyen servidores, y cerca de una cuarta parte dijo que sus servidores no tienen ninguna autenticación. Eso puede funcionar en una herramienta que corre en una sola computadora, pero no en nada expuesto a la red.

Tres reglas cierran casi toda esa brecha:

• El agente actúa como el usuario, nunca como una cuenta de servicio compartida. Tokens de OAuth ligados a la persona, para que el agente solo pueda hacer lo que esa persona tiene permitido. Tu servidor acepta solo tokens emitidos para él y nunca los reenvía a las APIs que están detrás.
• Mínimo privilegio por herramienta. Una herramienta que lee facturas no debería tener un token que pueda borrarlas.
• Las acciones de escritura esperan a una persona. Todo lo que envía, borra o gasta se detiene en un paso de aprobación que tu servidor exige, no en uno que esperas que el cliente de IA muestre. Son los mismos puntos de aprobación que hacen confiables las funciones con agentes dentro de tu propio producto.

¿Qué cambió en la especificación MCP de julio de 2026?

Si empiezas hoy, diseña para la revisión 2026-07-28 de la especificación y confirma qué revisiones soportan los clientes de IA a los que apuntas. Tres cambios importan para un equipo B2B:

1. MCP ahora es stateless (sin estado). La revisión elimina las sesiones a nivel de protocolo y el handshake de inicialización, y cada request lleva su propia versión del protocolo y sus capacidades, así que un servidor puede correr detrás de un balanceador de carga o en una plataforma serverless sin sticky sessions.
2. El registro de clientes cambió. El Dynamic Client Registration de OAuth queda deprecado a favor de los Client ID Metadata Documents. Confirma que tu proveedor de identidad los soporte.
3. El tracing quedó documentado. La especificación ahora describe cómo viaja el contexto de trazas de OpenTelemetry con cada request, para que puedas seguir la llamada de un agente desde el cliente de IA hasta tu propio backend.

Trata el tráfico de agentes como un tipo de cliente nuevo

Los agentes no se comportan como un navegador ni como un socio de integración. Reintentan, disparan llamadas en paralelo y corren a las 3 de la mañana en nombre de alguien que está dormido. Dales sus propios rate limits por cliente y por usuario, un registro de auditoría de cada llamada a una herramienta con el usuario en cuyo nombre actuó, y alertas cuando el token de un usuario llama a una herramienta de escritura más veces de lo que lo haría una persona. Es la misma disciplina que aplicas a una API pública, ahora frente a un cliente que no se cansa.

Una primera versión que vale la pena lanzar

Empieza con algo lo bastante pequeño como para aprender: un servidor de solo lectura, tres herramientas orientadas a tareas y un cliente de IA que controles, por ejemplo el asistente de tu equipo de soporte. Mide qué herramientas se llaman, qué llamadas fallan y qué pide la gente que ninguna herramienta cubre. Esa última lista es tu roadmap. Agrega herramientas de escritura solo cuando la parte de solo lectura se haya ganado la confianza, y siempre con aprobación.

Un servidor MCP toca tres prácticas a la vez: AI para el diseño de las herramientas, Secure para la autenticación y la auditoría, y Build para la API que está debajo. Por eso lo planteamos como un solo trabajo multipráctica, no como tres entregas entre equipos. Y si tus agentes van a leer datos de clientes, define quién puede ver qué antes de lanzar la primera herramienta.

Relacionados: Agentes de IA más allá del chatbot → · Tu función de IA necesita un patrón de UX → · RAG en producción →