Crea tu servidor MCP para prompts en 2026

Model Context Protocol (MCP) es el estándar abierto de Anthropic (2024) que permite conectar Claude y otros LLMs con herramientas, datos y prompts personalizados a través de una arquitectura cliente-servidor. Cuando construís un servidor MCP para prompts, estás centralizando y versionando templates de mensajes que inicializan conversaciones específicas, permitiendo que múltiples usuarios o aplicaciones reutilicen instrucciones de calidad sin duplicarlas.

Qué es Model Context Protocol (MCP)

Ponele que tenés un prompt bárbaro para code review que escribiste hace 6 meses y funciona piola, pero lo tenés guardado en un .txt, otro colega lo tiene en Notion con variaciones, y el tercero lo copypastea de un email. Cada versión es ligeramente distinta (spoiler: no debería). Eso es lo que intenta resolver MCP.

MCP es un protocolo estandarizado —definido por Anthropic en 2024— que funciona como un puente cliente-servidor. El cliente (Claude Desktop, VS Code con Copilot, o cualquier LLM compatible) se conecta a servidores que exponen tres tipos de capacidades: tools (funciones que ejecutan código), resources (datos de solo lectura), y prompts (templates de mensajes). La comunicación usa JSON-RPC 2.0 sobre stdio (local) o HTTP (remoto).

No es un estándar que Anthropic inventó y guardó en la bóveda, sino que es open source y otros están construyendo servidores MCP para GitHub, Slack, bases de datos, y servicios customizados. GitHub Copilot ya lo usa, y cada vez más herramientas se integran.

Los tres pilares de MCP: Tools, Resources y Prompts

Si vos accedés a un servidor MCP desde Claude Desktop, vas a ver tres cosas cuando el servidor se conecte. Acá viene lo bueno: son conceptos distintos y confundirlos es lo #1 en errores cuando empezás.

• Tools: Son funciones. Las invocas, ejecutan lógica con efectos secundarios (escriben archivos, llaman APIs, borran datos). Claude puede llamarlas dentro de una conversación, pasando argumentos. Ejemplo: un tool que consulta una base de datos y retorna resultados.
• Resources: Son datos que exponés de solo lectura. Claude puede referirse a ellos en el contexto de la conversación. Ejemplo: un archivo de configuración, un documento de arquitectura, un log. Claude los puede analizar pero no modificarlos.
• Prompts: Son templates de mensajes. Cuando invocás un prompt desde el cliente, el servidor retorna el contenido completo del template (a veces con placeholders dinámicos que el cliente rellena). No es una función —es un mensaje pre-escrito que inicializa una conversación específica.

El punto clave: un prompt es el equivalente a una instrucción que guardarías en un archivo y copypastearías al principio de una conversación. Un tool es lo opuesto —es algo que Claude ejecuta *durante* la conversación. Un resource está en el medio: está ahí para que Claude lo lea, pero no lo ejecuta.

Por qué construir un servidor MCP para prompts

Tomá cualquier empresa mediana: tienen 5-10 prompts de calidad para tareas recurrentes (debugging, code review, documentación, análisis de logs). Hoy, cada uno está en un lugar distinto. Para compartirlo, copypastean. Para actualizarlo, nadie sabe si salió una versión mejorada. Para usarlo en una herramienta nueva (un IDE plugin, un script, una API), necesitás refactorizar el texto. Relacionado: ejecutar agentes sin API local.

Un servidor MCP para prompts soluciona esto: tenés una fuente única de verdad, versionás los cambios (git o versionador propio), exponés los prompts donde sea necesario, y cualquiera puede invocar “code-review-prompt v2.3” sin saber dónde vive realmente.

Casos reales:

• Coherencia de instrucciones: Si tu equipo escala de 5 a 15 personas, querés que todos usen el mismo prompt para code review. Un servidor MCP lo garantiza.
• Prompts dinámicos según contexto: El servidor puede retornar versiones distintas del mismo prompt según el lenguaje del proyecto, el framework, la complejidad del módulo.
• Auditoría y control: Tenés logs de qué prompt se usó, cuándo, con qué versión. Útil si detectás que una versión anterior producía alucinaciones.
• Integración con herramientas no LLM: Tu IDE plugin, tu CLI, tu web app —todos hablan el protocolo MCP y obtienen el prompt actualizado sin duplicación.
• Sharing entre equipos: Si tu empresa tiene múltiples equipos (backend, frontend, infra), podés compartir prompts curados sin que cada uno reinvente la rueda.

Arquitectura de un servidor MCP: cómo funciona la conexión

Cuando arrancás Claude Desktop con un servidor MCP configurado, el flujo es así:

Claude (cliente) inicia una conexión al servidor → servidor responde con sus capacidades (qué tools, resources, y prompts expone) → Claude renderiza esas capacidades en la interfaz (botones, dropdowns, contexto inyectado) → vos seleccionás o invocás algo → Claude envía un request JSON-RPC al servidor → servidor procesa y retorna el resultado → Claude muestra el resultado en la conversación.

Para prompts específicamente: Claude no ejecuta el prompt, solo lo obtiene del servidor. Vos lo activás (ej: `/invoke prompt:code-review`) o Claude lo detecta automáticamente si está configurado como “default context” → servidor retorna el texto del template (posiblemente rellena placeholders como `{language}`, `{project_name}`) → Claude inicializa la conversación con ese texto completo.

La magia: todo pasa sobre JSON-RPC 2.0, que es un protocolo simple pero poderoso. Permite errores typed, reintento automático, y funciona tanto local (stdio) como remoto (HTTP). Eso sí, la conexión es 1:1 (un cliente a un servidor), no hay broadcast.

Construir tu primer servidor MCP: requisitos y setup

Necesitás:

• Node.js 20+ (20.10 mínimo para features recientes)
• TypeScript 5+ (MCP está escrito en TS, aunque podés usar JS puro si querés)
• npm o yarn
• El SDK oficial: npm install @modelcontextprotocol/sdk

Tenés dos caminos: usar la CLI de scaffolding (más rápido) o build manual (más control). Claude Code docs tiene ambas rutas. La CLI te genera la estructura en 2 minutos:

npx @modelcontextprotocol/create-mcp MyPromptServer --type prompts

Eso te crea una carpeta con un servidor base que expone prompts. Abrís el archivo `server.ts`, ves la estructura, registrás tus prompts, y listo. La estructura base incluye handlers para los métodos de MCP (listPrompts, getPrompt, etc.) ya esqueletizados. Sobre eso hablamos en opciones seguras para alojar tu código.

Pasos prácticos para exponer prompts desde tu servidor

Una vez tenés la estructura scaffoldizada, el flujo es:

1. Define tu prompt como objeto: nombre, descripción, argumentos opcionales (ej: `{language}`, `{context}`), y el contenido del template. 2. Registrá en el servidor usando `server.setRequestHandler(ListPromptsRequestSchema, …)` (para listar) y `GetPromptRequestSchema` (para obtener uno específico). 3. Levantá el servidor con `npm start` o `ts-node server.ts`. 4. Verificá la conexión desde Claude Desktop (logs en `.claude/logs/`). 5. Invocá el prompt desde Claude y validá que el template se inyecta correctamente.

Ejemplo de un prompt para code review:

“`javascript
const prompts = [
{
name: “code-review”,
description: “Template for peer code reviews”,
arguments: [
{ name: “language”, description: “Programming language (js, py, go, etc)” },
{ name: “focus”, description: “Focus areas (performance, security, style)” }
]
}
];
“`

Cuando Claude invoque `code-review` con `language=python` y `focus=security`, el servidor retorna el template con esos valores inyectados. Si querés prompts estáticos (sin argumentos), es aún más simple: solo nombre y contenido.

Conectar tu servidor MCP con Claude Desktop

El servidor está corriendo, pero Claude Desktop no sabe que existe. Necesitás configurarlo en el archivo de configuración:

• Mac/Linux: ~/.claude/claude.json
• Windows: %AppData%\Claude\claude.json

Agregás una entrada como esta:

“`json
{
“mcpServers”: {
“my-prompts”: {
“command”: “node”,
“args”: [“/path/to/your/server/dist/index.js”],
“type”: “stdio”
}
}
}
“` Más contexto en herramientas especializadas en IA.

Para servidores remotos, reemplazás `type: stdio` con `type: http` e incluís la URL. Reiniciás Claude Desktop, esperás 3-5 segundos, y si todo está bien, ves los prompts del servidor disponibles en la interfaz. Si hay error, revisá los logs en `~/.claude/logs/` para debug.

Ejemplos reales de servidores MCP con prompts en producción

No estamos hablando de teoría. Hay servidores MCP corriendo en producción hoy:

Langfuse Prompt Management

Langfuse expone un servidor MCP que conecta con su plataforma de versionado de prompts. Podés guardar prompts en Langfuse, y desde Claude Desktop (o tu CLI) invocás uno por nombre y versión. Langfuse maneja el versionado, A/B testing, y tracking de uso.

mcp-prompts (sparesparrow)

El repositorio mcp-prompts en GitHub es un servidor open source que expone prompts curados. Lo levantás localmente, exponés tus prompts, y cualquiera en tu red puede usarlos. Es un buen punto de partida si querés un servidor minimalista.

Servidores internos de equipos

Equipos en empresas medianas han construído servidores MCP internos que exponen prompts específicos por rol: prompts para PMs (análisis de requirements), para devs (debugging), para QA (test generation), para docs (documentación). Así, cada rol tiene sus prompts curados sin confundirse con los de otros. El control de acceso lo maneja el mismo servidor (validando usuario/token).

Errores comunes cuando construís un servidor MCP para prompts

No pensar en argumentos dinámicos desde el inicio

Construís un prompt para code review, lo exponés, funciona. Tres meses después, necesitás versiones distintas para Python vs Go vs Rust. Si no pensaste en argumentos (placeholders), tenés que crear tres prompts separados. Mejor: desde el inicio, define qué partes del prompt pueden variar según contexto. Mantenimiento futuro te lo agradecerá.

Olvidar que los prompts retornados se inyectan como contexto completo

Algunos esperan que al invocar un prompt, el servidor lo ejecute automáticamente. Nope. El servidor *retorna* el texto, y Claude lo inyecta como mensaje. Vos sos quien luego interactúa con ese mensaje. Eso significa: si el prompt es malísimo, la culpa es del prompt, no del servidor. Diseñá buenos prompts desde el principio.

No versionár los prompts

Actualizás un prompt en producción, rompe el workflow de alguien que dependía de la versión anterior, y nunca lo sabés porque no hay git ni changelog. Use git o un sistema de versionado. MCP no lo obliga, pero es una buena práctica. Langfuse lo hace por vos, si querés delegar. En plataformas para versionar el proyecto profundizamos sobre esto.

Comparativa: Formas de centralizar prompts en 2026

MCP gana cuando necesitás compartir, versionár, y dinamismo. Si es solo vos en un proyecto, el overhead probablemente no valga.

Preguntas Frecuentes

¿Qué es Model Context Protocol y para qué sirve exactamente?

MCP es un protocolo abierto (JSON-RPC 2.0) que estandariza cómo los LLMs acceden a herramientas, datos y prompts externos. Sirve para conectar Claude (y otros LLMs) con tus servicios sin duplicar código. En vez de que cada integración implemente su propio protocolo, todos usan MCP.

¿Cuál es la diferencia entre un prompt, un tool y un resource en MCP?

Un prompt es un template de mensaje que inicializa una conversación. Un tool es una función que Claude ejecuta *durante* la conversación (con efectos secundarios). Un resource es datos de solo lectura que Claude puede consultar. Prompt = texto pre-escrito. Tool = función ejecutable. Resource = dato referenciable.

¿Es difícil crear un servidor MCP o hay herramientas que faciliten?

Hay una CLI que scaffoldiza la estructura en 30 segundos. El SDK de MCP hace el heavy lifting (JSON-RPC, validación, errores). Si sabés TypeScript/Node.js básico, tardás 15-20 minutos en un servidor funcional. No es difícil si seguís el template.

¿Dónde puedo ver ejemplos de servidores MCP funcionando?

El GitHub oficial de MCP tiene una colección de servidores. También está mcp-prompts de sparesparrow como referencia minimalista, y tutoriales paso a paso en Dev.to.

¿Puedo exponer mis prompts propios en MCP sin conocer TypeScript profundamente?

Sí. El scaffolding te da un template casi completo. Reemplazás el contenido del prompt, cambias nombres y argumentos, y levantás el servidor. No necesitás dominar TS si seguís la estructura.

Conclusión

Crear un servidor MCP para prompts es útil cuando tenés (1) prompts que compartes entre varias personas o herramientas, (2) necesidad de versionado y auditoría, o (3) casos donde el prompt varía según contexto. Si escribís un prompt una sola vez y lo usás vos solo, es overkill. Si es algo que tu equipo usa constantemente y evoluciona, MCP es limpio.

Langfuse lo hace por vos si querés delegar. Si preferís control total, un servidor MCP minimalista en Node/TS te cuesta 20 minutos. El punto es que hoy, en 2026, ya no hace falta guardar prompts en txt o copypastearlos entre apps. MCP resolvió eso.

Fuentes

• Model Context Protocol – Specification (Anthropic)
• Claude Code Documentation – MCP Guide
• Official MCP Servers Repository
• Langfuse Prompt Management with MCP
• mcp-prompts: Open Source Prompt Server