Servidores MCP para agentes: qué son y cuándo crear uno

Qué es MCP

El Model Context Protocol (MCP) es un estándar abierto, presentado por Anthropic en noviembre de 2024 y adoptado después por muchos proveedores y herramientas de IA, para conectar aplicaciones de IA con sistemas externos. Un servidor MCP expone capacidades; un cliente MCP —una app de chat, un asistente del IDE o un framework de agentes— las descubre y las usa.

Un servidor puede ofrecer tres tipos de cosas: herramientas (acciones que el modelo puede invocar, como “buscar tickets” o “crear factura”), recursos (datos que la aplicación puede leer, como ficheros o registros) y prompts (plantillas reutilizables). Los servidores se ejecutan en local mediante entrada y salida estándar, o en remoto sobre HTTP.

Por qué importa

Antes de MCP, cada aplicación de IA necesitaba su propia integración con cada sistema. Con MCP describes tu sistema una vez y cualquier cliente compatible puede usarlo. Para una empresa de producto, significa que los clientes pueden conectar tu producto con las herramientas de IA que ya usan. Para un equipo interno, una sola integración sirve a todos los asistentes y agentes de la empresa.

Cuándo crear un servidor MCP

• Quieres que tus clientes usen tu producto desde los asistentes y agentes de IA que ya tienen.
• Varios agentes o asistentes internos necesitan las mismas herramientas y datos.
• Quieres una única puerta de acceso bien gobernada a los sistemas internos, con autenticación y registros coherentes.
• Tu equipo ya mantiene una API y una capa MCP encima es un añadido ligero.

Cuándo no

• Estás creando una sola función de IA dentro de una aplicación con un único modelo: el function calling directo es más sencillo.
• Las acciones son de alto riesgo (pagos, borrado de datos) y no hay un plan de permisos y aprobación humana.
• Tu API de base aún no es estable; arregla eso primero.

Diseñar buenas herramientas

Los modelos eligen herramientas por su nombre, descripción y esquema de entrada, así que escríbelos para alguien que no sabe nada de tu sistema. Mejor pocas herramientas concretas (“find_customer_by_email”, “list_open_tickets”) que una sola con muchos modos. Devuelve resultados compactos y estructurados con IDs que el modelo pueda usar en la siguiente llamada, y mensajes de error útiles cuando la entrada es incorrecta.

Separa lectura y escritura. Las herramientas de solo lectura suelen poder ejecutarse libremente; las que cambian datos deben exigir el permiso adecuado y, en acciones importantes, un paso de confirmación en el cliente.

Seguridad

Los servidores remotos deben usar una autorización adecuada —la especificación de MCP se apoya en OAuth— y cada token debe llevar solo los permisos que el usuario tiene realmente. Registra cada llamada a herramientas con quién la hizo y qué cambió. Y sobre todo, recuerda que los resultados de las herramientas acaban en el contexto del modelo: un ticket, un email o una página web devueltos por una herramienta pueden contener texto que intente dar nuevas instrucciones al modelo. Trata la salida de las herramientas como datos, limita lo que puede hacer una sesión y mantén a una persona en el proceso para cualquier acción destructiva.

Cómo empezar

Existen SDK oficiales para TypeScript, Python y otros lenguajes, y paquetes de la comunidad para PHP y Laravel. Empieza con dos o tres herramientas de solo lectura sobre una API existente, pruébalas con MCP Inspector y un cliente real, observa cómo las usa el modelo y afina las descripciones antes de añadir acciones de escritura. La calidad de un servidor MCP depende menos del protocolo que de unas herramientas claras y unos permisos cuidados.