Escribir un servidor MCP pasó de ser un experimento de fin de semana a una habilidad que te piden en entrevistas. El registro oficial listaba 47,267 servidores activos al 21 de octubre, el protocolo ahora lo aloja la Linux Foundation y lo soportan OpenAI, Google y Microsoft. Cuando los tres grandes se ponen de acuerdo en un formato, ya no es una apuesta de un solo proveedor.
Lo bueno para ti: hoy armar uno te toma una tarde. Lo que cuesta no es el código, es decidir qué expones y con qué permisos. Vamos a eso.
Qué cambió este año y por qué recién ahora conviene
La revisión vigente de la especificación es la 2026-07-28, y fue el cambio más grande desde que se agregó autorización. El punto gordo: se quitó el seguimiento de sesión a nivel de protocolo, así que MCP quedó stateless en esa capa. Traducido a tu trabajo diario, tu servidor ya no asume que el cliente recuerda nada entre llamadas; si necesitas estado, lo manejas tú y lo manejas explícito. Eso hace que desplegar detrás de un balanceador deje de ser un dolor de cabeza.
Y el movimiento sigue. En noviembre salió el server oficial v2.3.0 (4 de noviembre) con controles más finos: configuración opt-in para filesystem y fetch, y operaciones de Git separadas. El SDK de TypeScript llegó a la 2.4.0 con soporte de Skills sobre MCP, scopes opt-in para refresh de OAuth y mejor reenvío de eventos del servidor. El SDK oficial de Ruby alcanzó el nivel Tier 1 con conformidad del 100%. O sea: si antes lo descartaste porque "estaba verde", ese argumento se venció.
Qué expone realmente un servidor MCP
Mucha gente cree que un server MCP es "una API para la IA". Se parece, pero la diferencia importa: tu servidor no solo responde, también se describe. El modelo lee esa descripción y decide solo cuándo usarte. Hay tres tipos de cosas que puedes publicar:
- ▸Tools: acciones que el modelo puede ejecutar. Buscar un pedido, crear un ticket, correr una consulta. Es lo que más vas a usar.
- ▸Resources: datos que el cliente puede leer, identificados por URI. Un archivo, una tabla, un documento de políticas.
- ▸Prompts: plantillas reutilizables que el usuario invoca a propósito. Es la parte que casi todos ignoran y la que más agradece el equipo que lo use después.
Si tu primer server expone cuatro tools bien nombradas, ya le ganaste al 80% de lo que hay publicado.
El paso a paso que yo seguiría
Primero: elige un caso donde ya pierdas tiempo. No inventes un "server de clima" como los tutoriales. Si cada semana entras al panel de tu CRM a buscar lo mismo, ese es tu server. El criterio es simple: algo que hagas seguido, que tenga una API o una base detrás, y que no borre nada en la primera versión.
Segundo: elige SDK. Python y TypeScript son los caminos más cómodos y los mejor documentados; Ruby ya está en Tier 1 si tu stack es Rails. Arranca con transporte stdio, que corre local y no te obliga a montar nada en la nube. HTTP lo dejas para cuando otros lo usen.
Tercero: escribe una sola tool y pruébala. Define el esquema de entrada con tipos y describe qué hace en una frase que tenga sentido para alguien que no conoce tu sistema. Esa descripción es literalmente lo que el modelo lee para decidir si te llama. He visto tools perfectas que nunca se usaron porque decían "ejecuta consulta" en vez de "busca pedidos de un cliente por RUC o correo".
Cuarto: conéctalo a un cliente real y úsalo una semana. Claude Code es el banco de pruebas más cómodo porque ves en vivo qué tool eligió y con qué argumentos. Ahí descubres los nombres ambiguos y los parámetros que nadie entiende.
Quinto, y recién al final: agrega escritura. Crear, actualizar, borrar. Con confirmación y con límites. Si llegas acá sin haber usado el server en lectura por unos días, te vas a arrepentir.
La trampa clásica: exponer una tool genérica tipo "ejecuta este SQL". Es cómoda de programar y es un agujero. Expón operaciones concretas con parámetros acotados, no un intérprete.
Los errores que casi todos cometemos
El primero es de permisos. Tu servidor corre con las credenciales que le diste, no con las del usuario que está conversando. Si le pusiste una llave de administrador, cualquiera que hable con ese agente tiene permisos de administrador por interpósita persona. Por eso la v2.3.0 agregó configuración opt-in para filesystem y fetch: la idea es que el acceso se prenda a propósito, no por defecto.
El segundo es de contexto. Cada tool que publicas ocupa espacio en la ventana del modelo. Un server con cuarenta tools no es más potente, es más confuso: el modelo elige peor y te cuesta más por llamada. Mejor tres servers chicos y claros que uno gigante.
El tercero es de errores. Cuando tu tool falla, devuelve un mensaje que el modelo pueda usar para corregirse: "no encontré el cliente, el RUC debe tener 11 dígitos" sirve; un stack trace de 40 líneas solo quema contexto.
Cómo lo pasas de tu máquina al resto del equipo
Acá es donde la mayoría de servers mueren. Funcionan en la laptop de quien los escribió y nunca salen de ahí. Tres decisiones te evitan ese final.
La primera es el transporte. Con stdio cada persona corre su propia copia y usa sus propias credenciales, que para herramientas internas suele ser lo correcto. Con HTTP tienes un solo servicio central, más fácil de actualizar pero con la responsabilidad de autenticar a cada quien. Como la spec de julio dejó el protocolo sin estado de sesión, montarlo con varias instancias detrás de un balanceador ya no requiere trucos raros.
La segunda es el versionado de las descripciones. Cambiar el texto de una tool cambia el comportamiento del agente, aunque el código sea idéntico. Trátalo como cambio de producto: anótalo, avisa y deja la versión anterior disponible unos días.
La tercera es el registro. Si es interno, basta un repositorio con instrucciones de instalación de cinco líneas. Si lo vas a abrir, el registro oficial es donde lo van a buscar; nada más ten claro que publicar significa soportarlo.
Cuándo no hacer un servidor MCP
Si lo que quieres es un flujo fijo (llega un correo, extrae datos, guarda en una hoja, avisa por WhatsApp), no necesitas MCP: necesitas una automatización. Para eso n8n te resuelve en una tarde lo que en código te toma una semana. MCP tiene sentido cuando quieres que el modelo decida qué hacer, no cuando tú ya sabes el orden de los pasos.
Y si tu problema es orquestar varios pasos con memoria, reintentos y aprobación humana en el medio, un server MCP es solo una pieza: lo que te falta es un grafo de agente. Ahí entra LangGraph, que es la herramienta para esa parte.
Dónde seguir
MCP es la puerta de entrada, no el oficio completo. El rol que hoy se paga es el de quien lleva agentes a producción: arquitectura, memoria, evaluación, costos y monitoreo. Esa es la ruta de AI Agentic Engineer, y el camino corto para empezar hoy mismo es el curso de Claude Code para developers, donde vas a estar conectando servers MCP desde la primera semana.
Si recién estás eligiendo por dónde entrar al tema, mira el catálogo de cursos y arranca por el que te deje publicando algo esta semana. Tu primer server no tiene que ser bueno: tiene que existir y ahorrarte una tarea real.
Y si te sirve construirlo acompañado, cada semana armamos cosas así en vivo en la Comunidad AI Builders (desde 19 USD al mes). Llevar tu server a medio hacer y que alguien te diga por qué el modelo no lo llama vale más que diez tutoriales.
