Qué es MCP (Model Context Protocol): guía del protocolo

MCP fue anunciado por Anthropic en noviembre de 2024 como un estándar abierto para conectar modelos de lenguaje con fuentes de datos externas. La especificación es pública y está en modelcontextprotocol.io.

Desde su lanzamiento fue adoptado por un ecosistema creciente: Claude Desktop, Cursor, Zed, Sourcegraph, Replit, Cline y muchos otros clientes y servidores comunitarios. Hoy existen cientos de servidores MCP públicos (para GitHub, Slack, Postgres, Google Drive, Jira, etc.).

Antes de MCP, cada integración entre un LLM y una herramienta era un desarrollo custom. Si querías que Claude leyera tu GitHub, había que escribir código específico. Si querías que Cursor leyera tu Postgres, otro código distinto. Cada cliente × cada herramienta = una integración diferente.

MCP estandariza eso con dos piezas:

• Servidor MCP: programa que expone capacidades (tools, recursos, prompts) en un formato común.
• Cliente MCP: cualquier aplicación con un LLM (Claude, Cursor, tu propio agente) que sabe cómo hablar con servidores MCP.

Es exactamente la metáfora del USB-C: cualquier dispositivo con puerto USB-C se conecta con cualquier cable USB-C. Cualquier cliente MCP se conecta con cualquier servidor MCP.

💡 La diferencia clave con las integraciones custom: el cliente no necesita saber nada específico del servidor. Descubre sus capacidades al vuelo. Un cliente puede conectarse a un servidor MCP que se creó después que él, sin actualizar nada.

Esta es la tabla que más gente busca. Los tres conceptos se confunden todo el tiempo porque los tres conectan LLMs con datos externos, pero resuelven problemas distintos.

Los tres son complementarios, no excluyentes. Un buen agente moderno combina los tres. La comparativa a fondo está en MCP vs function calling vs RAG. Si quieres ver cómo funciona la recuperación de documentos, lee RAG local explicado sin jerga.

Para entender MCP en concreto, hace falta conocer tres piezas. El procedimiento de abrir una sesión está en cómo funciona MCP paso a paso. Los casos de uso no técnicos —para qué sirve un servidor, qué es un mcp-handler— están en servidores MCP: para qué sirven.

Servidor MCP

Programa que expone capacidades en formato estándar. Típicamente expone:

• Tools: funciones que el LLM puede invocar (ej. create_issue, search_emails, get_repo_status).
• Resources: datos que el LLM puede leer (ej. contenido de un archivo, registro de una DB).
• Prompts: plantillas de prompt predefinidas.

Cliente MCP

Aplicación con un LLM que sabe hablar el protocolo. Descubre las capacidades del servidor al conectarse y las ofrece al modelo. Ejemplos: Claude Desktop, Cursor, Cline, o tu propio agente custom.

Transport

Cómo se comunican cliente y servidor por la red. Los dos principales:

• stdio: el servidor es un proceso que el cliente lanza y con el que habla por entrada/salida estándar. Útil para servidores locales (ej. uno que lee archivos de tu máquina).
• HTTP + SSE / Streamable HTTP: el servidor es un servicio remoto al que el cliente se conecta por HTTP. Útil para servidores compartidos o en la nube.

Para que no quede en teoría, veamos cómo se implementa en Hito, un gestor de proyectos local-first con asistente IA. Hito combina las tres tecnologías que vimos arriba, cada una en su papel.

1. Function calling nativo (lo que usa el asistente dentro de la app)

El asistente IA de Hito, dentro de la aplicación, no usa MCP para funcionar. Usa function calling nativo de Gemini sobre unas 40 herramientas (tools) custom, definidas con schemas Zod y convertidas a FunctionDeclaration de Gemini. Algunas de esas tools son:

• create_task, update_task, list_tasks — manejo de tareas.
• get_project, list_projects, summarize_project_health — lectura de proyectos.
• add_area, update_area — gestión de áreas.
• create_checklist_template, apply_type_to_project — operaciones compuestas.
• semantic_search — búsqueda semántica (esta tool dispara el RAG que veremos abajo).

El propio código llama a esta capa "estilo MCP" (MCP-style) porque replica las ideas de MCP (tools con schemas, separación read/write), pero no usa el SDK oficial de MCP. Es una implementación directa sobre Gemini.

2. RAG local (para contexto semántico)

Cuando activas el asistente y tu workspace está indexado, antes de cada turno se ejecuta una búsqueda semántica sobre tus proyectos, tareas, checklists y personas. Los 5 resultados más relevantes se inyectan en el prompt para darle contexto al modelo.

Implementación verificada en el repo:

• Embeddings: generados con gemini-embedding-001 (de Google).
• Vector store: no hay base de datos vectorial externa. Los embeddings se guardan en IndexedDB del navegador.
• Similitud: cosine similarity calculada en JavaScript puro, en el cliente. Búsqueda lineal, sin ANN.
• Indexación: manual, la dispara el usuario desde Ajustes.

3. Servidor MCP oficial (para interoperabilidad externa)

Además de la capa interna, Hito expone un servidor MCP real usando el SDK oficial @modelcontextprotocol/sdk con transporte stdio. Es decir: cualquier cliente MCP externo (Claude Desktop, Cursor, etc.) puede conectarse a Hito y leer su workspace como si fuera otra fuente de datos.

El servidor MCP standalone hoy es read-only con fixtures de ejemplo. No es el camino que usa el chat de la app; está pensado para que terceros integren Hito en sus propios agentes en el futuro.

Por qué esta separación importa

La distinción no es académica. Tiene consecuencias prácticas:

• Dentro de la app, function calling directo es más simple y rápido que levantar un servidor MCP. No hay overhead de protocolo.
• Hacia afuera, MCP permite que otros agentes (Claude, Cursor, lo que sea) lean tus proyectos de Hito sin que Hito tenga que integrarse con cada uno.
• RAG agrega entendimiento semántico que ni function calling ni MCP dan por sí solos.

Hito es local-first: tus proyectos viven en archivos .json en tu equipo, sin backend. Pero cuando interactúas con el asistente IA, el contenido relevante de tu workspace viaja a la API de Gemini (Google) — incluyendo el system prompt con el índice de tus proyectos, los resultados del RAG semántico y las respuestas de las tools de lectura que el modelo invoque.

Tú traes tu propia API key de Google AI Studio, así que controlas qué modelo usas. Pero si trabajas con datos extremadamente sensibles, puedes simplemente no activar el asistente: el resto de Hito funciona 100% local, sin que un solo byte salga de tu equipo.

Esta precisión importa más que cualquier claim exagerado de marketing. Si tu caso de uso no tolera que los datos viajen a Google, no actives el asistente. Si lo tolera, el asistente es muy útil.

Depende de tu perfil:

La pregunta correcta para la mayoría no es "¿uso MCP?" sino "¿las herramientas que uso se integran bien con mi stack?". MCP es una respuesta técnica a esa pregunta, no la pregunta misma.

MCP es un protocolo de interoperabilidad que resuelve un problema real (cómo se conectan los LLMs con fuentes externas sin integraciones custom de a una). No es magia, no reemplaza a function calling ni a RAG, y no te va a cambiar la vida como usuario final. Pero para quien construye agentes, es probable que se convierta en el estándar por defecto en los próximos años.

Si quieres ver cómo se combinan las tres tecnologías — function calling, RAG local y un servidor MCP — en un gestor de proyectos real y open source, prueba Hito. Sin cuenta, sin nube (para el storage), y con un asistente IA que tú controlas con tu propia API key.