Servidores MCP: para qué sirven (sin ser developer)

Anthropic anunció el Model Context Protocol en noviembre de 2024. La analogía que se quedó es la del USB-C para la IA: un conector común, no una app nueva. El mapa conceptual está en qué es MCP; acá importa la pieza que busca quien escribe “servidores MCP” o “mcp's”: el programa del lado de tus datos.

El chatbot es el cliente (Claude, Cursor, un agente propio). El servidor MCP es lo que enchufa para leer un Drive, un repo, una base o un tablero. Sin servidor, el modelo solo tiene el texto que le pegas en el chat. Con servidor, pide acciones y datos en un formato que cualquier cliente MCP entiende. La especificación está en modelcontextprotocol.io.

Un servidor MCP no “piensa”. Expone tres tipos de capacidades. No tiene que ofrecer las tres:

Cómo se abre una sesión y se descubren esas capacidades, paso a paso, está en cómo funciona MCP paso a paso. MCP no reemplaza a function calling ni a RAG: es el cable. La comparativa está en MCP vs function calling vs RAG.

El anuncio de Anthropic ya listaba servidores de ejemplo: Google Drive, Slack, GitHub, Git, Postgres y Puppeteer. Traducido a trabajo de proyectos:

• Buscar en tus archivos de proyecto. “¿Dónde quedó el alcance del cliente B?” El servidor busca; tú no pegas tres PDFs en el chat.
• Crear una tarea desde una nota de reunión. El asistente lee la nota y pide “crea esta tarea”. El modelo no guarda nada: el servidor habla con el tablero.
• Consultar una base sin poner la clave en el prompt. Un servidor Postgres corre en tu entorno; las credenciales no entran al texto que le mandas al modelo.
• Revisar un sitio de staging. Un servidor como Puppeteer abre la página y trae lo que ve (un título roto, un 404). Check rápido, no un reemplazo de QA.
• Abrir issues en GitHub desde un standup. “Esto quedó como bug” se vuelve un issue creado por el servidor, no copiado a mano.

El patrón es el mismo: el asistente decide qué pedir; el servidor sabe cómo hacerlo contra una herramienta real.

Si llegaste buscando “mcp-handler”, no es un producto aparte. Es el nombre que a veces se le da al código (o al proceso) que recibe el pedido y corre la herramienta.

MCP habla JSON-RPC: el cliente dice “ejecuta esta tool con estos argumentos”. El mcp-handler escucha, valida que la tool existe, la corre y devuelve el resultado. Si no está corriendo, el asistente no ve tools. No necesitas escribir uno para usar MCP: cuando conectas un servidor en Claude Desktop o Cursor, el handler ya viene incluido. En uso diario, es “la parte que de verdad ejecuta”.

Un servidor MCP puede correr en tu máquina o en un servicio remoto. El protocolo es el mismo; cambia dónde se ejecuta el handler y, con eso, dónde tocan los datos.

• Local: el cliente lanza un proceso en tu computadora (stdio). Lee el disco, un tablero local, una base que solo existe ahí. Encaja cuando no quieres subir el workspace para que el asistente lo “conozca”.
• Remoto: el cliente se conecta por HTTP a un servicio (GitHub, Slack, un Drive). Útil cuando los datos ya viven en esa API.

Local no es un firewall. Si el tool llama a una API, esos datos salen. Y si el asistente usa un modelo en la nube, el resultado que el servidor devuelve puede viajar al proveedor. El servidor local evita subir el archivo entero “por las dudas”; no borra qué sale en cada turno. Esa distinción está en asistente de IA para proyectos sin entregar tus datos.

El caso más cercano a “que el asistente vea mi trabajo sin subir la empresa a una nube” es un gestor de proyectos local-first. El workspace vive en archivos en tu equipo. Un servidor MCP local es el adaptador: el asistente pregunta por proyectos o un resumen; el servidor lee y responde. El workspace no se “carga” a un producto de terceros para indexarlo.

Hito encaja en ese dibujo: gestor local-first que puede exponer el workspace a un cliente MCP sin que el tablero viva en un servidor ajeno. El chat de la app no depende de MCP para funcionar; MCP es el camino hacia afuera. Cómo se recupera contexto sin una base vectorial externa está en RAG local explicado sin jerga.

• No es un modelo. No “entiende” tu empresa por sí solo: expone tools y datos. El razonamiento lo hace el cliente con el LLM.
• No es un plugin de un chat concreto. Un plugin de ChatGPT vive en ese producto. Un servidor MCP lo puede usar cualquier cliente del protocolo.
• No reemplaza permisos. Si puede crear issues o leer un Drive, quien conecte el cliente hereda esa capacidad. Elige el mínimo de tools.

Si quieres el protocolo, empieza por qué es MCP. Si quieres enchufar el primer servidor, sigue cómo funciona MCP paso a paso. Esta página es el para qué: un adaptador, no un chatbot.