MCP (Model Context Protocol)

Protocolo abierto para conectar LLMs a herramientas externas, datos y sistemas de forma interoperable y descubrible. Estandariza el contrato entre un agente IA y los recursos a los que necesita acceder, eliminando el “integration tax” que cada tool integration requería antes.

La progresión histórica (ByteByteGo 2026-05-05)

Tool use → Function calling → MCP

EtapaCaracterísticaLimitación
Tool use (early agents)El LLM decide cuándo invocar una herramienta.Cada provider/framework tiene su API; no portable.
Function calling (OpenAI 2023)Schema estructurado del LLM que dice “quiero llamar X(args)“.Sigue siendo provider-specific; el cliente debe ejecutar.
MCP (Anthropic 2024+)Protocolo cliente-servidor: cualquier MCP server expone tools/resources/prompts a cualquier cliente.Costo: más tokens de contexto vs CLI directa (ver tensión abajo).

Refleja madurez de industria, no moda: el patrón “agente + herramientas” pasó de prototipo a infraestructura con contrato propio.

Los tres pilares no-negociables en producción (Pinterest 2026-05-12)

“MCP es infraestructura, no un shortcut — requiere el mismo rigor que cualquier servicio en producción.”

  1. Discovery (registry) — un agente debe poder enumerar tools disponibles sin hardcoding.
  2. Auth — granular por tool y por scope; principio de menor privilegio.
  3. Versioning — los contratos cambian; los agentes en producción no pueden romperse silenciosamente.

Cuando Pinterest cubrió las tres dimensiones, el “integration tax” desapareció: las nuevas capacidades de agentes se volvieron aditivas en vez de exigir refactor cada vez.

Tensión: MCP vs CLI (ByteByteGo EP210, 2026-04-11)

EjeMCPCLI
Tokens de contextoMás caros (schema completo + descripciones)Más baratos (el modelo ya sabe sintaxis Unix)
DiscoverabilityAlta (registry estandarizado)Baja (depende de manual/help)
ComposabilidadPor handoff explícito entre toolsPipe/redirect/Unix philosophy
Trust boundaryServer controla qué exponePermisos del shell del usuario

Ni gana siempre. Para herramientas con sintaxis Unix-friendly y composabilidad nativa, CLI directa puede ser más eficiente. MCP gana cuando hay muchas tools heterogéneas que el agente necesita descubrir y combinar dinámicamente.

Seguridad — zero trust for agents (ByteByteGo 2026-05-05)

GitHub diseñó su arquitectura agentic asumiendo que el agente ya está comprometido desde el inicio:

  • Sandboxing por defecto.
  • Permisos granulares por acción.
  • Auditoría por acción individual.

El patrón se vuelve estándar de industria en 2026 — cualquier deploy serio de agentes en producción adopta zero-trust como baseline. Esto convierte MCP en vector de seguridad además de vector de funcionalidad: cada server expuesto es superficie de ataque.

Casos de aplicación documentados

CasoPatrónFuente
PinterestProduction MCP ecosystem (discovery + auth + versioning)ByteByteGo 2026-05-12
Figma Design-to-CodeScreenshot agota contexto, JSON crudo es opaco; MCP permite extracción selectiva — el agente pide solo lo que necesitaByteByteGo 2026-05-11
GitHub Agentic WorkflowZero-trust for agents como principio arquitectónicoByteByteGo 2026-05-05
MCP + Playwright + Jira (QA workflow)Cadena E2E: agente ejecuta Playwright, reporta a Jira via MCPMedium Nikolaynesvitiy 2026-04-30
Claude Platform on AWSManaged Agents + MCP connectors + Skills, todo en un solo billSuperintelligence 2026-05-13
Metricool (B2C / community managers)MCP server expone API; Claude analiza Reels y categoriza vídeos por temática — capacidad no nativa del producto. Ver vicent-marti-metricool.Modo Inteligente Podcast nov 2025

Frame del comprador agente (Greg Isenberg 2026-05-13)

Sin MCP server = invisible para el nuevo comprador (agentes).

Si los compradores B2B en 2026 son humanos asistidos por agentes (o agentes con autorización), las APIs y productos sin MCP exposing son literalmente no-descubribles para esa capa de decisión. Implicación: el moat ya no es solo distribución — es distribución + memoria del agente + presencia en el catálogo MCP.

Confirmación desde mercado consumer (Metricool): el frame aplica también B2C. Metricool — plataforma para community managers — expone MCP server antes que sus competidores directos (Hootsuite, Buffer, Later). En el momento en que un community manager prompts a Claude “sácame las métricas de mis Reels”, Metricool es el único producto invocable. Es ventaja temporal de adopción temprana, pero la implicación estructural es la misma: la categoría B2C también se está redistribuyendo según presencia MCP.

MCP vs Skills (ByteByteGo EP213, 2026-05-03)

EjeMCPSkills
Qué haceConecta herramientas externasEncapsula comportamientos predefinidos reutilizables
Cuándo usarNecesidad de flexibilidad dinámicaNecesidad de consistencia reproducible
RelaciónComplementarios, no sustitutos

Skills es Anthropic-specific (Claude Code/Claude Apps). MCP es protocolo abierto. Los Skills pueden invocar MCP servers; la inversa no aplica.

Posición en el wiki

  • Refuerza vibe-coding como capa técnica que estandariza la conexión agente↔herramientas.
  • Conecta con agentic-patterns (catálogos de patrones de agentes asumen MCP como capa estándar).
  • Conecta con agent-memory (servers MCP pueden exponer memoria persistente como recurso).
  • Tensión productiva con arquitectura-software — los pilares Pinterest (discovery/auth/versioning) son arquitectura de servicios aplicada a un nuevo dominio.

Update mayo 2026 — AI Engineer Conference 2025

ai-engineer-agentes-mcp-evals-agregada formaliza las primitivas del protocolo y aporta el frame canónico del problema que resuelve:

Las 3 primitivas del servidor MCP

  1. Tools (herramientas): funciones ejecutables orientadas a la acción (buscar en Google, ejecutar código, enviar correo).
  2. Resources (recursos): datos estáticos o dinámicos que el agente lee para obtener contexto (registros de BD, contenido de archivos, estado).
  3. Prompts (instrucciones): plantillas predefinidas que guían al agente sobre cómo interactuar de forma óptima con los recursos y herramientas del servidor.

El “Mega Context Problem” — el problema que originó MCP

Antes de MCP, para que un agente supiera qué tools usar había que inyectar las descripciones de cientos o miles de APIs en su ventana de contexto:

  • Agotaba tokens rápidamente.
  • Aumentaba costos y latencia.
  • Confundía al modelo — entraba en la “zona torpe” (dumb zone) donde la capacidad de razonamiento decae (cross-link con context-engineering).

Progressive Discovery = la solución que MCP habilita: el agente descubre tools/data/prompts dinámicamente en tiempo de ejecución, busca y carga solo lo relevante cuando lo necesita.

Casos de uso documentados (AI Engineer Conf)

TipoImplementaciones canónicas
BDsPostgreSQL, BigQuery — leer schemas, SQL, generar mock data
NavegadoresPlaywright — autonomous browsing, screenshots, auditorías de accesibilidad, comparar Figma vs implementación
Code/CIGitHub — repos, issues, hilos de discusión, generar PRs
ProductividadSlack, Linear, Asana, Salesforce
Grafos de conocimientoNeo4j — traducir lenguaje natural a Cypher → graphrag
Deep researchBúsqueda web + extracción + transcripción YouTube combinadas

Gateways como capa empresarial

Cross-link con arquitectura-software: las empresas implementan Gateways MCP en el medio para gestionar:

  • Autenticación (OAuth).
  • Control de acceso basado en roles.
  • Monitoreo.
  • Límites de seguridad.

Esto evita codificar esta lógica directamente en cada agente — patrón equivalente al API Gateway de microservicios aplicado al dominio agentic.

Fuentes

Preguntas abiertas

  • ¿MCP escala a millones de tools en el registry, o emerge un sub-protocolo de search-within-MCP?
  • ¿La adopción de MCP por Apple/Google/Microsoft completaría el efecto red, o lo fragmentaría?
  • ¿Existe métrica de “MCP debt” análoga a comprehension-debt — agentes que invocan MCP sin que nadie del equipo sepa qué expone realmente?