Todo proyecto de agentes de IA acaba chocando con el mismo muro: el modelo es listo, pero no ve tu CRM, tu ERP ni tu wiki interna. Hasta hace poco, cada conexión era una integración a medida escrita para un proveedor de modelos y una aplicación concretos. El Model Context Protocol (MCP) cambia eso al dar a las aplicaciones de IA una forma única y abierta de comunicarse con herramientas y datos. Esta guía explica qué es MCP, cuándo merece la pena adoptarlo, cómo diseñar un servidor MCP para un sistema de negocio y cómo mantenerlo seguro.
Qué es MCP, en un párrafo
MCP es un protocolo abierto que estandariza cómo se conectan las aplicaciones de IA con fuentes de datos y herramientas externas. Anthropic lo presentó en noviembre de 2024 (Anthropic, 2024) y en diciembre de 2025 lo donó a la Agentic AI Foundation, un fondo neutral bajo la Linux Foundation entre cuyos miembros platino están AWS, Anthropic, Google, Microsoft y OpenAI (Linux Foundation, 2025). La especificación se versiona por fecha; la revisión actual es la 2026-07-28.
La mejor analogía viene de la propia especificación: MCP hace por las herramientas de IA lo que el Language Server Protocol hizo por los editores de código. En lugar de que cada editor implemente soporte para cada lenguaje, cada lenguaje ofrece un servidor y cualquier editor puede usarlo.
Cómo funciona MCP: hosts, clientes y servidores
Los mensajes de MCP usan JSON-RPC 2.0 entre tres roles (especificación de MCP):
- Host: la aplicación de IA en la que trabaja el usuario, como una app de chat, un IDE o un asistente interno.
- Cliente: el conector dentro del host que mantiene la conexión con un servidor.
- Servidor: un servicio que expone contexto y capacidades, por ejemplo "nuestro CRM" o "nuestro almacén de documentos".
Los servidores ofrecen tres tipos de funciones:
| Función | Quién la controla | Ejemplo en un sistema de negocio |
|---|---|---|
| Tools | El modelo decide cuándo llamarlas | create_invoice, search_customers, get_stock_level |
| Resources | La aplicación o el usuario eligen | Un contrato en PDF, una lista de precios, el esquema de una base de datos |
| Prompts | El usuario elige una plantilla | "Resume el último trimestre de este cliente" |
Los clientes pueden ofrecer elicitation: un servidor puede pedir al usuario la información que falta a mitad de la tarea en lugar de adivinarla. Las extensiones opcionales añaden tareas de larga duración y elementos de interfaz interactivos.
Por qué importa para las empresas
Sin un estándar, conectar tres aplicaciones de IA con cinco sistemas internos significa quince integraciones, cada una con su autenticación, su manejo de errores y su mantenimiento. Con MCP, construyes cinco servidores una vez y cualquier host compatible con MCP puede usarlos.
Los beneficios prácticos que veo:
- Sin dependencia del proveedor. El mismo servidor funciona con asistentes de distintos proveedores de modelos, porque el protocolo lo gobierna ahora una fundación neutral y no una sola empresa.
- Una frontera de seguridad por sistema. El control de acceso, los registros y los límites de frecuencia viven en el servidor, junto a los datos, no en los prompts.
- Pilotos más rápidos. Una vez que tu ERP tiene un servidor MCP, un nuevo asistente para ventas o soporte es sobre todo trabajo de prompts y de experiencia de usuario.
- Reutilización entre equipos. El asistente de informes del equipo de finanzas y el agente del equipo de soporte llaman a la misma herramienta
get_order.
MCP no sustituye a una buena recuperación. Para preguntas sobre grandes colecciones de documentos sigues necesitando indexación, búsqueda híbrida y reranking, como se describe en RAG para empresas. MCP es la forma en que el agente llega a esa búsqueda y a los sistemas estructurados que nunca deberían "adivinarse" a partir de texto.
Cuándo MCP no es la herramienta adecuada
- Un único workflow fijo. Si tu código siempre llama a las mismas tres APIs en el mismo orden, una función normal o un motor de workflows es más sencillo.
- Movimiento masivo de datos. MCP está pensado para un acceso interactivo dirigido por el modelo, no para un ETL nocturno de millones de filas.
- Sistemas sin una API estable. Un servidor MCP es una capa fina y bien diseñada sobre una API existente. Si la propia API no es fiable, arregla eso primero.
Diseñar un servidor MCP para un sistema de negocio
La calidad de un agente depende mucho de la calidad de sus herramientas. Algunas reglas que sigo:
- Diseña las herramientas en torno a tareas, no a endpoints. Una herramienta
find_customer(query)que busca por nombre, correo o identificador fiscal es mejor que tres endpoints de bajo nivel que el modelo tiene que encadenar. - Escribe las descripciones para el modelo. La descripción de la herramienta es en la práctica parte del prompt: di qué hace, cuándo usarla y qué devuelve.
- Devuelve resultados compactos y estructurados. Veinte campos relevantes, no el registro completo de 200 campos. Las cargas grandes desperdician contexto y dinero.
- Haz explícitos los efectos secundarios. Separa las herramientas de lectura (
get_invoice) de las de escritura (post_invoice) y exige confirmación para todo lo que mueva dinero o envíe mensajes. - Falla de forma informativa. "Cliente no encontrado; prueba a buscar por identificador fiscal" ayuda al modelo a recuperarse; un stack trace, no.
Este es un servidor mínimo de solo lectura en Python con el helper FastMCP del SDK oficial:
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("crm")
@mcp.tool()
def find_customer(query: str, limit: int = 5) -> list[dict]:
"""Search customers by name, email or tax ID.
Use this before any customer-specific action. Returns id, name,
email, segment and open_balance for up to `limit` matches."""
rows = crm_db.search_customers(query, limit=limit) # your existing data layer
return [
{"id": r.id, "name": r.name, "email": r.email,
"segment": r.segment, "open_balance": float(r.balance)}
for r in rows
]
@mcp.resource("crm://customers/{customer_id}/summary")
def customer_summary(customer_id: str) -> str:
"""Plain-text account summary for a single customer."""
return crm_db.render_summary(customer_id)
if __name__ == "__main__":
mcp.run()
Empieza en solo lectura. Añade herramientas de escritura solo cuando tengas registros que muestren cómo usa el modelo las de lectura con preguntas reales.
Seguridad: la parte que no te puedes saltar
MCP da a un modelo la capacidad de leer datos y ejecutar acciones, así que los principios de seguridad de la especificación no son lectura opcional. Los hosts deben obtener el consentimiento explícito del usuario antes de invocar herramientas, las descripciones de herramientas de servidores no confiables deben tratarse como no confiables y los datos del usuario no deben enviarse a otro sitio sin consentimiento (especificación de MCP: seguridad).
En la práctica:
- Autentica a los usuarios, no al agente. Para servidores remotos, la especificación define un flujo de autorización basado en OAuth (autorización en MCP). Cada llamada a una herramienta debería ejecutarse con los permisos de la persona que lo pidió, para que el agente nunca pueda ver más de lo que vería esa persona.
- Instala solo servidores de confianza. Unos investigadores han demostrado el "tool poisoning", en el que un servidor malicioso oculta en la descripción de una herramienta instrucciones que el modelo sigue (Invariant Labs, 2025). Revisa los servidores de terceros como cualquier otra dependencia.
- Evita la trifecta letal. Un agente con acceso a datos privados, expuesto a contenido no confiable y capaz de comunicarse con el exterior puede ser engañado para filtrar datos (Simon Willison, 2025). Rompe al menos una pata en cada workflow.
- Registra cada llamada. Quién lo pidió, qué herramienta, qué argumentos, qué se devolvió. Lo necesitarás para depurar, para auditorías y para responder a incidentes.
Trato el prompt injection y el modelo de amenazas completo en seguridad de agentes de IA: prompt injection y el OWASP Top 10 para LLM.
Un plan de despliegue que funciona
| Fase | Duración | Entregable |
|---|---|---|
| 1. Elegir un sistema y un caso de uso | 1 semana | Una lista de 20–50 preguntas reales que hacen los usuarios |
| 2. Servidor de solo lectura | 1–2 semanas | 3–6 herramientas, OAuth, registros |
| 3. Piloto con 5–10 usuarios | 2–4 semanas | Sesiones registradas, análisis de fallos, mejores descripciones de herramientas |
| 4. Herramientas de escritura con confirmación | 2 semanas | Acciones como crear tickets o borradores |
| 5. Ampliar | continuo | El siguiente sistema, convenciones de herramientas compartidas |
Mide el piloto como cualquier funcionalidad de IA: tasa de éxito de las tareas, tasa de errores de herramientas y con qué frecuencia los usuarios tienen que corregir al agente. Mi forma de medir está en cómo evaluar aplicaciones LLM. Si tu sistema principal es Odoo, consulta integrar agentes de IA con Odoo para ver un ejemplo concreto.
Guías relacionadas
Los servidores MCP son tan buenos como las herramientas que exponen; consulta diseño de herramientas para agentes LLM. Para equipos Java, Spring AI admite MCP de serie (guía de Spring AI), y las decisiones de arquitectura sobre agentes están en workflows frente a agentes.
Preguntas frecuentes
¿MCP es solo para Claude? No. MCP es un protocolo abierto gobernado por la Agentic AI Foundation bajo la Linux Foundation, y lo admiten aplicaciones y SDK de muchos proveedores.
¿Necesito MCP si ya tengo una API REST? Tu API REST se queda. Un servidor MCP es una capa fina por encima que describe tu API de forma que la entiendan las aplicaciones de IA y añade consentimiento, autenticación y registros adecuados para agentes.
¿Servidores locales o remotos? Los servidores locales encajan con herramientas de desarrollo y aplicaciones de escritorio. Para sistemas de negocio compartidos por un equipo, usa servidores remotos con OAuth para que el acceso se gestione y audite de forma centralizada.
¿Cuánto se tarda en construir uno? Un servidor de solo lectura para un sistema con una API decente suele llevar de una a dos semanas, incluidos autenticación y registros. La mayor parte del esfuerzo se va en el diseño de herramientas y en las pruebas con preguntas reales.
Fuentes
- Anthropic (2024). Introducing the Model Context Protocol.
- Linux Foundation (2025). Formation of the Agentic AI Foundation; MCP joins the Agentic AI Foundation.
- Model Context Protocol. Specification, revision 2026-07-28 y Authorization.
- Invariant Labs (2025). MCP security notification: tool poisoning attacks.
- Simon Willison (2025). The lethal trifecta for AI agents.