Que tus agentes trabajen sobre tus sistemas, no sobre capturas de pantalla.
Un servidor MCP es la puerta por la que Claude, Cursor o tu propio agente entran a tu base de datos, tu API y tus procesos. Lo diseño acotado, con permisos de verdad, y construido contra la revisión vigente del protocolo.
Empezamos con una llamada de descubrimiento, sin costo ni compromiso.
Lo que cubre el servicio
De decidir qué se expone a dejarlo corriendo y conectado. El código que escribe el servidor es la parte corta del trabajo.
Diseño de la superficie
La decisión que más pesa no es cómo se implementa, es qué se expone. Salimos de la llamada con la lista de herramientas que el agente necesita de verdad, y con la lista de las que no van a existir.
Herramientas, recursos y prompts
Las tres primitivas del servidor, cada una para lo suyo. Esquemas de entrada estrictos, descripciones que el modelo entiende sin adivinar, y errores que dicen qué hacer en vez de reventar la conversación.
Autorización y alcance
Quién puede llamar a qué. Permisos por herramienta y no por servidor, credenciales fuera del contexto del modelo, y separación entre lo que solo lee y lo que escribe.
Transporte y despliegue
stdio para lo local, Streamable HTTP para lo remoto. Desde que el núcleo del protocolo dejó de tener estado, un servidor MCP encaja en serverless sin la sesión pegada a un proceso que antes lo impedía.
Observabilidad
Saber qué llamó el agente, con qué argumentos y cuánto tardó. La primitiva de Logging quedó deprecada, así que la traza va por stderr y OpenTelemetry, que es la ruta que marca la propia especificación.
Conexión desde los clientes
El servidor no sirve de nada si nadie lo enchufa. Dejo la configuración lista y probada para Claude Code, Cursor y el resto de hosts que hablen el protocolo, con su documentación de un solo comando.
Cuándo no necesitas un servidor MCP
MCP se ha vuelto la respuesta por defecto a preguntas que no siempre la piden. Para que no perdamos tiempo los dos, estos son los casos en los que te voy a decir que no.
- 00
Tienes una herramienta y un solo cliente
Si es una función y la va a llamar una sola aplicación tuya, el function calling del proveedor te resuelve el problema hoy y sin infraestructura nueva. MCP empieza a pagar cuando hay varias herramientas, o varios agentes distintos que quieren las mismas.
- 01
Lo que necesitas es buscar en documentos
Eso es un problema de recuperación, no de protocolo. Un pipeline de búsqueda bien montado te sale más barato y más rápido. Un servidor MCP puede ser la puerta de entrada a ese pipeline, pero no lo sustituye ni lo mejora por sí solo.
- 02
Quieres exponer toda tu API de una vez
Es el error más caro y el más común. Cada herramienta ocupa contexto y amplía la superficie de ataque, así que un servidor con doscientas herramientas rinde peor que uno con doce bien elegidas. Envolver el catálogo entero automáticamente no es un servidor MCP, es un problema con otro nombre.
- 03
Esperas que el servidor sea tu frontera de seguridad
No lo es, y conviene saberlo antes de firmar. El servidor autoriza llamadas, pero corre con las credenciales que le des y el agente que lo usa comparte el entorno de quien lo ejecuta. La frontera se dibuja en las cuentas y los permisos de los sistemas de abajo, y esa parte también la diseñamos.
- 04
Tu plan depende de Sampling o de Roots
Las dos quedaron deprecadas en la revisión vigente del protocolo, con retirada no antes de julio de 2027. Si tu arquitectura asumía que el servidor podía pedirle completions al host, hay que rehacerla contra la API del proveedor. Mejor descubrirlo ahora que a mitad de la construcción.
Ya mantengo uno en producción
ThatSEOAgent expone 57 herramientas de SEO por MCP contra las APIs de Google. No es una demo: es el servidor que uso a diario y el que me obliga a estar al día con cada revisión del protocolo.
Construirlo me dejó las cicatrices que se pagan una sola vez: dónde se rompe un servidor remoto en serverless, cuánto contexto se come un catálogo de herramientas mal recortado, y qué pasa cuando la especificación deprecia una primitiva sobre la que ya habías construido.
Esa experiencia también está escrita y la puedes leer antes de contratarme. Diez artículos sobre el protocolo, desde la introducción hasta el desmontaje de la revisión vigente, con las fuentes de la especificación citadas.
Un servidor real en producción, no un ejemplo de documentación.
Construido contra la versión vigente del protocolo, no contra tutoriales viejos.
Sobre el protocolo, sus transportes y sus deprecaciones. Con la spec citada.
Lo que te llevas
Un servidor que tu equipo puede mantener sin mí. Ese es el objetivo, no el retainer.
El servidor, y su repositorio
El código es tuyo desde el primer commit, sin lock-in. Con tests sobre las herramientas y las decisiones de diseño explicadas, para que otra persona pueda seguir el trabajo sin llamarme.
Herramientas documentadas
Cada una con su esquema, sus límites y su descripción escrita para que el modelo acierte a la primera. Es la diferencia entre un agente que resuelve y uno que prueba a ver qué pasa.
Permisos y credenciales resueltos
Autorización configurada, secretos fuera del contexto del modelo y el alcance de cada herramienta por escrito. Sabiendo qué puede tocar el agente y qué no.
Despliegue y trazas
El servidor corriendo donde tenga que correr, con las llamadas visibles. Para enterarte de que una herramienta falla antes de que te lo cuente el usuario.
Guía de conexión
Cómo lo enchufa tu equipo desde Claude Code, Cursor o el host que uséis, con el comando exacto. Un servidor que nadie sabe conectar no está terminado.
Preguntas frecuentes
Las dudas que salen siempre antes de decidir si vale la pena construir un servidor MCP.
¿Qué es un servidor MCP y por qué querría uno propio?
MCP es un protocolo abierto que estandariza cómo un modelo habla con herramientas y datos externos. Un servidor MCP es el programa que expone tus sistemas a través de ese protocolo. Tener uno propio importa cuando quieres que el agente trabaje sobre lo tuyo (tu base de datos, tu API interna, tu panel) y no solo sobre lo que ya viene empaquetado. La ventaja de que sea un protocolo y no una integración es que lo escribes una vez y lo consume cualquier host que lo hable, en lugar de repetir el trabajo por cada cliente. Si quieres el panorama completo antes de hablar conmigo, lo tengo escrito en qué es MCP y, con más profundidad, en MCP por dentro.
¿Por qué un servidor MCP y no function calling directo?
Si tienes una aplicación y una herramienta, function calling directo es la respuesta correcta y te ahorras una pieza. El servidor MCP gana cuando se cumple al menos una de tres cosas: las mismas herramientas las quieren consumir varios clientes distintos (tu producto, Claude Code, Cursor, el asistente interno del equipo), las herramientas son suficientes como para necesitar versionado y permisos propios, o quieres poder cambiar de proveedor de modelo sin reescribir las integraciones. Fuera de esos casos, montar un servidor es complejidad que no te está comprando nada.
¿Es seguro exponer mis sistemas por MCP?
Es tan seguro como lo diseñes, y el diseño es la mayor parte del trabajo. Tres reglas que aplico siempre: las herramientas se acotan a lo que el agente necesita de verdad, en lugar de envolver la API entera; las credenciales viven en el servidor y nunca pasan por el contexto del modelo; y lo que escribe se separa de lo que solo lee, con permisos distintos. Lo que no hay que asumir es que el servidor sea por sí mismo una frontera de seguridad: corre con los permisos que le des, así que la frontera real se dibuja en las cuentas de los sistemas de abajo.
¿Qué pasa cuando cambie la especificación?
Que va a cambiar es la única certeza. La revisión vigente, 2026-07-28, quitó el handshake de initialize y volvió stateless el núcleo del protocolo, y dejó deprecadas Sampling, Roots, Logging y el registro dinámico de clientes, con retirada no antes de julio de 2027. Eso rompe buena parte de los tutoriales que hay circulando, y lo conté en detalle en MCP se vuelve stateless. Construyo contra la revisión vigente, dejo por escrito de qué versión depende cada pieza y qué habría que tocar en la siguiente, y sigo la especificación de cerca porque escribo sobre ella.
¿Funciona con Claude, Cursor y ChatGPT?
Funciona con cualquier host que hable el protocolo, y esa es justamente la razón de usarlo. Claude Code, Claude Desktop y Cursor lo soportan de forma nativa, y el ecosistema de clientes crece cada mes. Lo que cambia entre uno y otro es la configuración, no el servidor: el mismo binario responde a todos. Entrego el servidor con la conexión probada en los hosts que use tu equipo.
¿En qué lenguaje lo construyes?
Por defecto TypeScript o PHP, que es donde tengo más kilómetros y donde suele estar el sistema que hay que exponer. La decisión real no suele ser de gusto: el servidor conviene escribirlo en el lenguaje del sistema al que se conecta, porque así reutiliza sus modelos, su autenticación y sus tests en vez de duplicarlos. Si tu backend es Laravel, el servidor va en PHP, y de hecho ese caso lo tengo documentado en MCP para Laravel.
¿Qué quieres que tu agente pueda hacer?
Empezamos con una llamada de descubrimiento, sin costo ni compromiso. Salimos de ahí con la lista de herramientas que necesitas, la de las que no, y si el problema se resuelve sin construir nada, te lo digo.