¿Qué es MCP realmente?
Model Context Protocol explicado sin marketing. Qué resuelve, qué no, y cuándo stdio gana a HTTP.
MCP es un protocolo a nivel de cable. Esa es toda la respuesta, y toda la confusión.
Empecé a construir servidores MCP en febrero de 2026. Los docs oficiales hablan de "tools, prompts, resources" como si fueran tres conceptos al mismo nivel. Después de 56 tools repartidos por seis servidores te digo la verdad: los tools son el 95 % del valor. Prompts y resources están bien. Tools es lo que hace que el modelo actúe.
Un tool en MCP es un endpoint JSON-RPC con un schema tipado. El modelo ve el schema, decide llamar al tool, envía argumentos, recibe una respuesta. Ese es todo el mecanismo. Todo lo demás (transporte, auth, discovery, multi-tenancy) envuelve ese único mecanismo.
Lo que los docs no te dicen: a MCP no le importa la latencia. El protocolo asume que estás local o en una conexión rápida. Si pegas MCP encima de una API remota lenta, el modelo se queda esperando y el usuario tiene una respuesta perezosa. Lo aprendí por las malas envolviendo una API REST pública detrás de MCP sin caché.
Cuándo gana MCP: tienes una superficie de acciones estructurada (un CRM, un almacén de memoria, un pipeline de vídeo), el modelo necesita invocar la acción, quieres seguridad de tipos en los argumentos. Cuándo pierde MCP: solo quieres que el modelo lea un documento. Para eso existe llms.txt. MCP es para verbos, llms.txt es para sustantivos.
Los repos de mi hub que lo demuestran: local-memory-mcp envuelve SQLite + FTS5 más un grafo de conocimiento detrás de 13 tools. mcp-personal-suite envuelve email, calendario, mensajería y cuatro dominios más detrás de 49 tools. mcp-video envuelve ffmpeg más Playwright detrás de 8 tools. Cada uno es un dominio expresado como verbos MCP, nada más.
Si recuerdas una sola cosa: MCP es el mecanismo con el que tu modelo actúa sobre un dominio. Elige el dominio primero, escribe los verbos después, elige el transporte al final.