Cómo crear un MCP Server para integrar LLMs con seguridad

MCP servers explicados: qué son, para qué sirven y cómo crear el tuyo

Entender los MCP servers explicados: qué son, para qué sirven y cómo crear el tuyo es importante si quieres conectar un LLM con datos y acciones de tu infraestructura sin abrir una caja negra insegura. El Model Context Protocol (MCP) busca estandarizar esa capa: separa el razonamiento del modelo de la ejecución real que hace tu código.

Documentación y recursos oficiales:

• Protocolo y spec
• Repo oficial
• SDK (Node)

Tiempo estimado de lectura: 4 min

Ideas clave

• Un MCP Server expone Resources (solo lectura), Tools (acciones ejecutables) y Prompts (templates) para clientes LLM.
• La comunicación puede ser por stdio (local) o SSE/HTTP (remoto) manteniendo credenciales en el servidor.
• Empieza con capacidades de solo lectura; exige confirmación humana para escrituras peligrosas.
• Implementa autenticación, rate limiting y auditoría con trace IDs para producción.

Introducción

Un MCP Server es un proceso ligero (local o remoto) que expone al cliente de IA tres tipos de capacidades bien definidas: Resources (solo lectura), Tools (acciones ejecutables) y Prompts (templates). El cliente (por ejemplo Claude Desktop, Cursor, Windsurf, o un agente en n8n) descubre esas capacidades y decide cuándo invocarlas. La comunicación suele usar stdio para ejecuciones locales o SSE/HTTP para conexiones remotas. Crucial: las credenciales y el acceso real permanecen en tu servidor; el LLM no las recibe.

Resumen rápido (lectores con prisa)

MCP es un protocolo para separar razonamiento (LLM) de ejecución (tu infra).

Expone Resources (lectura), Tools (acciones) y Prompts (templates) para clientes LLM.

Transporte: stdio local o SSE/HTTP remoto; credenciales se quedan en el servidor.

Útil para integrar múltiples clientes LLM con una capa única, segura y versionable.

Qué es un MCP Server

Un MCP Server publica capacidades que los clientes LLM pueden descubrir y usar en tiempo de ejecución. Las capacidades son:

• Resources: datos de solo lectura (esquemas, logs resumidos, métricas).
• Tools: acciones ejecutables con entradas definidas por esquema.
• Prompts: plantillas que combinan contextos y recursos relevantes.

Por qué usar MCP en vez de una API ad-hoc

• Estándar único: el mismo servidor puede trabajar con múltiples clientes LLM sin reescribir integraciones.
• Seguridad mejorada: las credenciales no viajan en prompts.
• Descubrimiento dinámico: el cliente lista herramientas y recursos disponibles en tiempo de ejecución.

Arquitectura mínima de un MCP Server

• Transporte: stdio (local) o SSE/HTTP (remoto).
• Registro de capabilities: lista de tools/resources que el servidor publica.
• Handlers: funciones que ejecutan las herramientas y devuelven contenido estructurado.
• Logging/auditoría: registros de llamadas, inputs y outputs con firma/trace-id.

Ejemplo práctico (Node.js + TypeScript)

Instalación y preparación

mkdir mi-mcp-server && cd mi-mcp-server
npm init -y
npm install @modelcontextprotocol/sdk
npm install -D typescript @types/node
npx tsc --init

Ejemplo mínimo: src/index.ts

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { ListToolsRequestSchema, CallToolRequestSchema } from "@modelcontextprotocol/sdk/types.js";
import os from "os";

const server = new Server({name:"mi-mcp", version:"0.1.0"}, {capabilities:{tools:{}}});

server.setRequestHandler(ListToolsRequestSchema, async ()=>({
  tools: [{ name: "get_system_info", description: "Info SO y memoria", inputSchema: { type: "object", properties: {}, required: [] } }]
}));

server.setRequestHandler(CallToolRequestSchema, async (req)=>{
  if (req.params.name === "get_system_info") {
    return { content: [{ type:"text", text: JSON.stringify({ platform: os.platform(), totalMemory: os.totalmem() }, null, 2) }] };
  }
  throw new Error("tool-not-found");
});

await server.connect(new StdioServerTransport());
console.error("MCP server listo");

Compila con npx tsc y ejecuta node dist/index.js. Para clientes como Claude Desktop registra el comando en su config (paths en macOS/Windows según documentación del cliente).

Qué exponer (y qué no)

Empieza por recursos de solo lectura y herramientas inofensivas:

• Recursos: esquemas de DB, logs resumidos, métricas con paginación.
• Tools (lectura): consultas parametrizadas que devuelven resultados limitados.
• Prompts: plantillas que pre-cargan recursos relevantes.

Evita al principio: comandos de escritura (DROP, DELETE), accesos de shell indiscriminados, o cualquier endpoint que pueda cambiar estado sin confirmación humana. Implementa siempre un flujo de validación humana para acciones críticas.

Producción: seguridad y operativa

• Autenticación y autorización: el servidor debe gestionar credenciales y validar cada petición con roles.
• Rate limiting y cuotas: evita que un prompt malicioso dispare herramientas repetidamente.
• Auditoría inmutable: registra request/response con trace IDs, timestamps y hashes del prompt.
• Testing: mocks para tools y tests end-to-end con clientes (stdio y SSE).
• Paginación y resumido: no envíes logs enteros; ofrece ventanas y resúmenes para preservar tokens.

Casos de uso reales y prácticas recomendadas

• Integración con n8n: usa el MCP Server como puente para disparar workflows desde lenguaje natural sin exponer credenciales a la interfaz.
• Revisión de PRs automatizada: expón diffs y reglas como recursos; la tool devuelve checklist y reportes en Markdown.
• Soporte operador: diagnóstico de infra mediante logs resumidos y herramientas read-only que recogen métricas.

Registra y versiona tus prompts y esquemas del MCP en el repo; trátalos como código crítico.

Conclusión

Los MCP servers explicados aquí son la pieza que convierte LLMs en componentes confiables dentro de una plataforma técnica. No es magia: es disciplina. Empieza pequeño (solo lectura), instrumenta todo, exige confirmación humana para escrituras y versiona los prompts. Si lo haces bien, tendrás agentes que razonan con seguridad y una única capa mantenible que conecta IA con tus sistemas.

Mención: Dominicode Labs

Para equipos que exploran automatización y agentes como parte de su plataforma técnica, puede ser útil revisar trabajos y prototipos en Dominicode Labs. Es una referencia contextual para enfoques de integración y experimentación práctica.

FAQ

¿Qué diferencia a un MCP Server de una API tradicional?

Un MCP Server define un estándar para que clientes LLM descubran y llamen capacidades (Resources, Tools, Prompts). Mantiene credenciales y lógica de ejecución en el servidor, evitando que se incrusten en prompts como suele pasar con APIs ad-hoc.

¿Cómo se comunican el cliente LLM y el MCP Server?

La comunicación común es por stdio para ejecuciones locales o mediante SSE/HTTP para conexiones remotas. El cliente consulta las capabilities y llama handlers definidos por el servidor.

¿Qué precauciones de seguridad debo implementar?

Implementa autenticación y autorización por roles, rate limiting, auditoría inmutable con trace IDs y validation humana para acciones que modifican estado.

¿Puedo exponer herramientas de escritura si las requisito?

Sí, pero siempre detrás de controles estrictos: confirmación humana, autorización granular, pruebas y registros completos. Evita exponer inicialmente comandos destructivos.

¿Cómo se versionan prompts y esquemas?

Registra y versiona prompts y esquemas en el repositorio del proyecto como parte del código crítico; aplica revisiones, pruebas y despliegues controlados.

¿Qué formatos de respuesta soportan las tools?

Las tools devuelven contenido estructurado (por ejemplo objetos JSON con bloques de tipo texto o markdown). El SDK y el spec del MCP describen los schemas esperados.

¿Cuál es el transporte recomendado para producción?

Para local, stdio es simple y seguro. Para entornos distribuidos, SSE/HTTP ofrece mayor flexibilidad; la elección depende de latencia, despliegue y requisitos de auditoría.