¿Qué es exactamente un servidor MCP?

Un modelo de lenguaje, por sí solo, no puede leer sus archivos, consultar su base de datos ni acordarse de ayer. Produce texto. Todo lo demás —cada acción, cada consulta— ocurre porque algún programa fuera del modelo fue y lo hizo.

Antes del Model Context Protocol, cada una de esas conexiones era a medida. Si quería que Claude leyera su Notion y que ChatGPT leyera su Notion, escribía dos integraciones contra dos sistemas de plugins distintos, y ninguna sobrevivía a la siguiente versión del proveedor. MCP es el acuerdo que acaba con eso: un servidor, cualquier cliente que hable el protocolo.

La forma general

Hay tres partes. El host es la aplicación que usted usa de verdad: un asistente de escritorio, un IDE, una interfaz de chat. El cliente vive dentro del host y gestiona una conexión. El servidor es la cosa que escribió usted u otra persona, y es quien tiene la capacidad: acceso a un sistema de archivos, a una instancia de Postgres, a un calendario, a un almacén de memoria.

Hablan JSON-RPC 2.0. No es un detalle en el que detenerse, pero vale la pena saberlo, porque significa que el conjunto es inspeccionable. Puede leer los mensajes. No hay ninguna capa mágica donde el modelo «decide» algo que usted no puede ver.

La secuencia es sosa a propósito: el cliente se conecta, las dos partes intercambian capacidades, el cliente pregunta qué ofrece el servidor, y a partir de ahí el modelo puede pedir una de esas cosas por su nombre. El servidor ejecuta. El resultado vuelve como texto que el modelo lee.

Las tres cosas que un servidor puede exponer

Casi todos los servidores con los que se cruzará usan la primera e ignoran las otras dos. Las tres merecen entenderse, porque la diferencia está en quién decide.

• Tools (herramientas) — funciones que el modelo puede llamar por iniciativa propia. `search_memory`, `create_issue`, `run_query`. El modelo lee su descripción de la herramienta y decide cuándo aplica. Ahí está la potencia, y ahí está el riesgo.
• Resources (recursos) — datos que lee el *host* y coloca en el contexto. Un archivo, un registro, un documento. No lo dispara el modelo, lo dispara la aplicación. Menos autonomía, más previsibilidad.
• Prompts — plantillas reutilizables que el usuario elige deliberadamente. Lo más parecido a un comando de barra.

Una consecuencia que se descubre tarde: la descripción de una herramienta no es documentación, son instrucciones para el modelo. Si una herramienta no se llama nunca cuando debería, el arreglo casi nunca está en el código: es que la descripción no supo decirle al modelo a qué situación pertenece. Reescribimos las nuestras exactamente por esa razón y la tasa de llamada cambió de inmediato.

Local o remoto: la elección que importa

Existen dos transportes, y elegir entre ellos determina casi todo lo que su instalación va a parecer.

stdio lanza el servidor como un proceso hijo en su propia máquina. El host ejecuta un comando, le habla por la entrada y la salida estándar, y lo mata al salir. Nada sale del dispositivo. Es la respuesta correcta para todo lo que toque archivos locales, y por eso los servidores de filesystem y de git funcionan como funcionan. El precio: solo existe en esa máquina. Su portátil y su teléfono no lo comparten, y el servidor solo está vivo mientras lo está la aplicación.

HTTP hace correr el servidor en algún sitio accesible. El host se conecta por la red, autenticándose normalmente con OAuth 2.0. A partir de ahí todos los dispositivos ven el mismo servidor, y un servicio alojado puede ser uno. El precio: está confiando en quien lo opera, y debería saber dónde corre, que es el tema de otro artículo de aquí.

Para la memoria en concreto, la decisión no está reñida. Una memoria que solo existe en un portátil es un cuaderno. Todo el sentido de la cosa es que el asistente que abre en otro dispositivo ya lo sepa.

Lo que un servidor puede hacerle

Un servidor MCP es código al que usted concedió el derecho de actuar. Trátelo en consecuencia.

Un servidor local corre con los permisos de su usuario: puede leer todo lo que usted puede leer. Uno remoto recibe todo lo que el modelo le envía, lo que con el tiempo es muchísimo sobre usted. Y la descripción de una herramienta es texto dirigido al modelo, así que un servidor puede moldear cómo se comporta el asistente, no solo responderle.

Cuatro preguntas que vale la pena hacerse antes de instalar uno:

1. ¿Puedo leer el código fuente, o es un binario de un desconocido?
2. ¿Qué permisos tiene: un único directorio, o todo mi directorio personal?
3. Si es remoto: ¿quién lo opera, en qué país, y puedo borrar mis datos?
4. ¿Escribe, o solo lee? Un servidor de solo lectura tiene un radio de impacto mucho menor.

El ecosistema es joven y está construido en su mayoría por individuos de buena fe. Eso no es lo mismo que auditado. El registro oficial y las listas comunitarias son herramientas de descubrimiento, no avales.

Cuándo debería escribir uno

El listón es bajo: un servidor que expone dos herramientas cabe en un archivo corto, en Python o en TypeScript, y los SDK se encargan del protocolo. La pregunta de verdad es si una herramienta es la forma adecuada para lo que quiere.

Suele serlo cuando el asistente necesita *actuar* sobre un sistema vivo, o recuperar algo que cambia. Suele no serlo cuando solo necesita que el modelo conozca un cuerpo de texto fijo: pegarlo, o exponerlo como recurso, es más simple y más fiable que enseñar al modelo a ir a pedirlo.

Si quiere los detalles, la especificación es corta y legible, lo cual es raro y dice algo bueno del proyecto.

Pryzm es un servidor MCP remoto cuyo único oficio es la memoria: almacena lo que usted le cuenta y recupera después las partes relevantes, en cualquier cliente que hable el protocolo. Si prefiere alojar el suyo, existen varios servidores de memoria autoalojables y gratuitos, y los listamos en nuestra comparativa.