Servidores MCP: el catálogo de referencia del que copias

La mayoría de los equipos descubren MCP por la vía lenta: leen la spec, se quedan mirando el formato de mensajes y luego tratan de escribir un servidor desde un archivo vacío. Esa es la puerta equivocada. La forma más rápida de entender el Model Context Protocol es leer servidores que ya funcionan, y el repo oficial «modelcontextprotocol/servers» existe justo para eso: es el catálogo canónico de implementaciones de referencia y un índice curado de las de la comunidad. Este texto es el recorrido práctico: qué hay de verdad en el repo, cómo conectar un servidor a Claude en un par de minutos, cuándo copiar en vez de escribir el tuyo, y las decisiones de seguridad que más pesan antes de darle a un modelo acceso real a un sistema.

01 · Qué es el repo en realidad

El repo son dos cosas distintas bajo un mismo nombre, y confundirlas genera enredos.

La primera es un conjunto reducido de servidores de referencia mantenidos que viven dentro del repo. Son los que los maintainers mantienen al día conforme el protocolo avanza, y de paso son el mejor material de aprendizaje que vas a encontrar: cortos, idiomáticos y correctos. La lista cubre las capacidades que casi todo agente termina necesitando.

• filesystem: leer, escribir y buscar archivos bajo una raíz que tú eliges.
• fetch: traer una URL y devolverle el contenido al modelo, al estilo web-a-texto.
• git: leer y operar sobre un repositorio local.
• memory: un almacén persistente simple de clave-valor donde el modelo escribe y vuelve a leer entre turnos.
• sequentialthinking: un andamiaje para razonar de forma estructurada, paso a paso.

La segunda cosa es un índice: una lista larga y curada en el README que apunta a integraciones oficiales mantenidas por empresas (bases de datos, APIs de SaaS, herramientas de dev) y a cientos de servidores de la comunidad. El índice no es código que clonas; es un mapa de quién ya construyó un servidor para lo que necesitas, para que no lo hagas de nuevo.

02 · Por qué MCP se gana un lugar en el stack

La gracia de MCP es la reutilización, y cuesta apreciarla hasta que sientes en carne propia el dolor que te ahorra.

Sin él, cada app que quiere que un modelo toque un sistema reimplementa la misma plomería: un schema de tool a la medida, un parser de argumentos, un formateador de resultados, una ruta de auth. Hazlo en tres apps y ya escribiste tres veces la misma integración de "deja que el modelo lea nuestra base de datos", cada una sutilmente distinta y cada una con su propia superficie de bugs.

Con MCP expones una capacidad una sola vez como servidor, y cualquier cliente compatible le habla por el mismo protocolo. Claude Code, la app de escritorio y un agente propio que escribiste pueden usar todos el mismo servidor de git sin trabajo extra por cada cliente. Las integraciones dejan de ser pegamento atado a cada app y pasan a ser unidades reutilizables e intercambiables: puedes reemplazar tu servidor de base de datos hecho a mano por el oficial de un proveedor sin tocar los clientes que dependen de él.

Hay un segundo beneficio, más callado, que para mí pesa más que la reutilización: MCP traza una frontera limpia entre el modelo y el sistema. El modelo solo puede hacer lo que permiten las tools del servidor. Esa frontera es donde pones tu seguridad, y un protocolo que la deja explícita es un protocolo que la hace defendible.

03 · Arranque rápido: conectar un servidor de referencia a Claude

La mayoría de los servidores de referencia no se instalan globalmente: dejas que el cliente los lance bajo demanda con un runner. Para los servidores en Node eso es «npx»; para los de Python es «uvx». La config del cliente le dice a Claude qué comando correr y qué argumentos pasarle, y los argumentos más importantes son los que acotan el servidor.

Esta es una config mínima de Claude Desktop que agrega el servidor de filesystem, encerrado a un único directorio de proyecto:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/tu/proyectos/ilustrari"
      ]
    }
  }
}

Ese path del final no es un detalle: es el sandbox. El servidor solo puede ver archivos bajo esa raíz. Si le das «/», le entregaste tu disco entero al modelo; si le das un proyecto, trazaste una cerca. Reinicia el cliente y Claude gana «read_file», «write_file», «list_directory» y compañía, todo confinado a ese árbol.

Para Claude Code la conexión es un comando en vez de un archivo editado a mano:

claude mcp add filesystem -- npx -y @modelcontextprotocol/server-filesystem /Users/tu/proyectos/ilustrari

04 · Leer un servidor para aprender el protocolo

El valor real de los servidores de referencia es que son lo bastante cortos como para leerlos completos. Un servidor hace tres cosas: declara sus tools (nombre, descripción y un JSON-Schema para las entradas), atiende las llamadas a esas tools y devuelve resultados en el formato de contenido del protocolo. Una vez que lees uno, la spec deja de ser abstracta.

Esta es la forma, destilada: declarar una tool y responder cuando el modelo la llama.

server.tool(
  "get_invoice",
  "Busca una factura por su id.",
  { id: z.string() },
  async ({ id }) => {
    const inv = await db.invoice(id)
    return { content: [{ type: "text", text: JSON.stringify(inv) }] }
  }
)

Tres cosas para fijarse, porque son el protocolo entero en miniatura:

1. La descripción es parte de la interfaz, no un comentario. El modelo la lee para decidir cuándo llamar la tool, así que una descripción vaga produce una tool que el modelo usa mal. Trátala como documentación que el modelo de verdad obedece.
2. El schema de entrada es tu primera línea de validación. JSON-Schema (o Zod compilado a él) restringe lo que el modelo puede mandar, pero es una pista para el modelo y un contrato para tu código, no una garantía de seguridad. Revalida en el servidor de todas formas.
3. El resultado es contenido, no un valor de retorno. Devuelves un arreglo de contenido (texto, y en los servidores más nuevos imágenes o recursos); por eso un servidor puede devolver resultados ricos, no solo strings.

05 · Cuándo copiar y cuándo escribir el tuyo

El repo te tienta a escribir un servidor para todo. Resístelo. La decisión es la misma que tomarías con cualquier dependencia: construye solo lo que es tuyo.

Usa un servidor que ya existe cuando

• La capacidad es genérica: leer archivos, traer URLs, hablar con git, consultar Postgres. Alguien ya lo resolvió, lo mantiene y parcheó los casos borde con los que tú todavía no te has topado.
• Hay un servidor oficial del proveedor para ese sistema (hoy muchos productos de SaaS y bases de datos traen uno vía el índice). Un servidor oficial sigue los cambios de la API del proveedor para que tú no tengas que hacerlo.
• Estás prototipando y quieres probar el protocolo antes de comprometerte a mantener algo.

Escribe el tuyo cuando

• La capacidad es específica de tu dominio: tu lógica de facturación, tu API interna, tu modelo de datos. No hay servidor ya hecho para tu negocio.
• La frontera de seguridad tiene que ser tuya. Cuando la tool toca sistemas sensibles, quieres controlar al detalle qué puede y qué no puede hacer, con auth y validación bajo tu control. En Infuse lo pienso justo así: una superficie de tools angosta y hecha a propósito siempre le gana a una genérica y ancha.
• Necesitas la capacidad disponible para más de un cliente: en cuanto dos clientes necesitan lo mismo a la medida, el servidor se paga solo.

Cuando escribas uno, no arranques de un archivo en blanco. Clona un servidor de referencia en tu lenguaje, recórtalo a una sola tool, haz que esa tool funcione de punta a punta y crece desde ahí. Heredas gratis la estructura del proyecto, la configuración del transporte y el formateo de resultados, y te ahorras toda una familia de errores del tipo "por qué el cliente no ve mi servidor".

06 · Las concesiones honestas y la realidad de seguridad

MCP es realmente bueno, pero adoptarlo tiene costos y un peligro que eclipsa al resto. Conócelos antes de conectar diez servidores a un agente en producción.

• Cada servidor es nueva superficie de ataque. Este es el que más pesa. Una tool que el modelo puede llamar es una tool que un atacante puede intentar alcanzar a través del modelo, con un payload de inyección de prompts escondido en un documento, una página web o un correo que el agente lee. Los servidores de fetch y filesystem son justo el tipo de capacidad ancha que la inyección adora. Acótalos y da por hecho que la entrada es hostil.
• El mínimo privilegio no es opcional. Nunca le des a un servidor una credencial de admin que sirva para todo. Dale un token acotado, un rol de solo lectura cuando solo necesitas leer, un único directorio en vez del disco entero. El radio de daño de un servidor comprometido es exactamente el privilegio que le diste.
• Valida las entradas en el servidor, siempre. El JSON-Schema restringe al modelo, no a un atacante que encuentre otra ruta hacia tu servidor. Revalida cada argumento en tu handler como si viniera de un cliente no confiable, porque en la práctica así fue.
• El reguero de config es real. Cada servidor es un proceso que el cliente levanta, una dependencia que mantener al día y un conjunto de tools que infla las opciones entre las que el modelo tiene que elegir. Pasado cierto punto, más tools no es más capacidad: es más confusión y más superficie. Mantén el conjunto ajustado.
• El versionado se mueve bajo tus pies. El protocolo y los servidores evolucionan. Fija versiones donde puedas y vuelve a probar después de un upgrade, en vez de dar por hecho que una config que funcionaba el mes pasado se comporta igual.

El repo «modelcontextprotocol/servers» es la mejor rampa de entrada a MCP precisamente porque enseña con el ejemplo: copia un servidor de referencia, córrelo acotado, lee su código y el protocolo encaja. Trata los servidores de referencia como tools y como libros de texto a la vez, apóyate en el índice antes de construir nada por tu cuenta y pon tu esfuerzo de ingeniería real en la frontera de seguridad que cada servidor representa. Acierta con el acotamiento y MCP convierte las integraciones en unidades limpias y reutilizables; fállalo y le entregaste a un modelo (y a quien pueda hablarle) una puerta a tus sistemas.