MCP (Model Context Protocol) es el estándar abierto que le permite a un LLM descubrir, autenticar y usar herramientas, datos y acciones de cualquier sistema externo de forma uniforme. Anunciado por Anthropic en 2024 y adoptado rápidamente por OpenAI, Google, IDEs, IDEs con IA, plataformas low-code y empresas que construyen sus propios agentes, MCP es hoy el equivalente al "USB-C de los agentes de IA".
Esta guía explica qué es MCP, por qué se volvió un estándar de facto, qué problema resuelve, cómo construir tu propio servidor MCP y cómo encaja en una arquitectura moderna de agentes.
El problema que existía antes del MCP
Antes del MCP, cada proveedor de LLM tenía su propio formato de tool use. Cada framework (LangChain, LlamaIndex, Vercel AI SDK, Mastra) reinventaba el esquema de herramientas. Conectar un agente a un sistema interno significaba escribir n × m integraciones: n agentes por m sistemas. Para las empresas con varios casos de uso y varios sistemas internos, esto se volvió una explosión combinatoria de glue code.
MCP elimina esa explosión. Escribes un servidor MCP una sola vez, exponiendo las herramientas y los datos de un sistema. Cualquier cliente MCP (Claude Desktop, un IDE, tu propio agente, una plataforma de automatización) consume esas herramientas sin reescribir nada. El estándar es declarativo, con schema, versionado y descubrimiento automático.
Arquitectura conceptual
MCP tiene tres piezas. Servidor MCP: expone resources (datos), tools (acciones) y prompts (templates reutilizables) de un sistema. Cliente MCP: descubrimiento, autenticación e invocación de las piezas del servidor. Vive dentro de un host (Claude Desktop, un IDE, un agente). Host: la aplicación que orquesta uno o más clientes y expone la experiencia al usuario final.
La comunicación ocurre vía JSON-RPC sobre stdio (para integraciones locales, como plugins de IDE) o sobre HTTP/SSE (para servidores remotos). El protocolo cubre handshake, descubrimiento de capacidades, autenticación, invocación, streaming de salida y cierre.
Casos de uso reales
Integración con una base interna de conocimiento: un servidor MCP expone búsqueda semántica sobre Confluence, Notion o Drive. Cualquier agente de la empresa consume esa búsqueda sin necesidad de duplicar la indexación. Operaciones en producción: un servidor MCP hace de wrapper de kubectl, terraform, AWS CLI; un agente de DevOps lo usa para diagnosticar incidentes con control del blast radius. Acceso a CRM y ERP: un servidor MCP transforma Salesforce, HubSpot o Pipefy en un conjunto de tools predecible. Automatización de codebase: un servidor MCP indexa el repositorio y expone búsquedas, refactor seguro, generación de tests; usado por copilots y agentes de ingeniería.
Cómo construir tu primer servidor MCP
El camino más rápido es usar el SDK oficial en TypeScript o Python. Define tools con nombre, descripción clara, JSON Schema de los argumentos y función de ejecución. Define resources con un URI estable y una función de lectura. Implementa autenticación (token, OAuth, mTLS) si el servidor expone datos sensibles. Empaquétalo como un CLI invocable y pruébalo con Claude Desktop o con un cliente MCP standalone.
Buenas prácticas: descripciones de tool cortas y directas, enfocadas en cuándo usar, no en cómo implementar. Un JSON Schema riguroso, con enums, mínimos y máximos. Mensajes de error accionables por el agente (los LLMs leen el error y vuelven a intentar). Idempotencia siempre que sea posible. Auditoría de las llamadas para trazabilidad.
Seguridad en MCP
MCP mueve el control de acceso al servidor. Esto está bien, pero exige disciplina. Cada tool debe tener el alcance mínimo, con un principle of least privilege riguroso. Las tools con efecto destructivo (delete, drop, terminate) necesitan confirmación explícita en el host, con un double-check del usuario. Los servidores que exponen datos personales necesitan respetar la LGPD/GDPR en el flujo: log de acceso, base legal, posibilidad de revocación. Y nunca expongas un servidor MCP público sin autenticación fuerte: es, en la práctica, una API que los LLMs van a usar con una creatividad que los humanos no usarían.
Por qué MCP se volvió estándar tan rápido
Tres motivos. Primero, fue abierto desde el día cero: spec pública, SDKs en múltiples lenguajes, sin amarre a un vendor. Segundo, resolvió un dolor real y creciente: el dolor de la integración combinatoria entre agentes y sistemas. Tercero, fue adoptado por quienes lo usan todos los días: la propia Anthropic dentro de Claude, IDEs, empresas con agentes en producción. Un estándar que nace del uso real le gana a un estándar que nace de un comité.
MCP vs frameworks de tool use propietarios
Todavía vas a ver tool use propietario en algunos lugares. Tiene sentido cuando el conjunto de herramientas es cerrado y el agente es monolítico. MCP brilla cuando quieres reutilizar las mismas herramientas en múltiples agentes, hosts y equipos, y cuando quieres desacoplar la evolución del servidor de la evolución del agente. En arquitecturas corporativas, MCP es casi siempre la mejor elección a largo plazo.
El futuro próximo: MCP, agentes autónomos y marketplaces
La próxima ola ya está ocurriendo. Están surgiendo marketplaces de servidores MCP (oficiales y comunitarios), que permiten conectar decenas de integraciones en minutos. Los agentes autónomos empiezan a descubrir y usar servidores MCP que nunca vieron antes, con handshake automático y una descripción leída directamente del servidor. Esto cambia profundamente la forma en que se integra el software: el "código de cola" entre sistemas tiende a desaparecer, reemplazado por servidores MCP autodocumentados.
Para las empresas, la recomendación es simple: trata MCP como una capability de plataforma. Ten un equipo que decida qué servidores exponer internamente, cuáles hospedar, cuáles consumir del mercado, con una gobernanza clara. Quien haga esto ahora va a componer agentes en horas donde los competidores todavía gastan semanas.