MCP a fondo: el Model Context Protocol, de punta a punta, para el operador de agentes

Cada post que escribimos sobre el stack agéntico — A2A, AP2, x402, ERC-8004 — referenció a MCP como si todos ya lo conocieran. Este es el post que deberíamos haber escrito primero. MCP es el protocolo que le permite a un agente hablarle a sus herramientas. Si el resto del stack estandariza cómo los agentes se hablan entre sí, cómo se pagan, y cómo prueban su identidad, MCP estandariza cómo cada uno de ellos hace su trabajo. Este post es el walkthrough exhaustivo que les debemos a todos los futuros operadores de agentes: arquitectura, las seis primitivas, los dos transports, OAuth 2.1, el modelo de seguridad, la spec actual 2025-11-25, el release candidate que viene 2026-07-28 (núcleo stateless, MCP Apps, Tasks como extensión formal), las preocupaciones del operador que la spec deja para que vos las resuelvas, y cómo Agent Builder convierte a MCP de un protocolo que implementás a una superficie de control que configurás.

La forma del problema que MCP resuelve

Antes de MCP, cada aplicación LLM que quería conectarse a una fuente de datos externa o una herramienta escribía un adaptador a medida. El agente que llamaba a GitHub tenía su propia integración a GitHub. El agente que llamaba a Notion tenía su propia integración a Notion. El agente que leía de Postgres tenía su propio wrapper de base de datos. Cuando querías conectar una nueva herramienta al agente, escribías código nuevo. Cuando querías conectar tu agente a una plataforma LLM distinta, reescribías la integración del otro lado. El problema tenía la misma forma que la web temprana antes de HTTP: cada cliente y cada servidor inventaban su propio protocolo; nada componía.

Anthropic open-sourceó MCP en noviembre de 2024 con el objetivo explícito de ser "USB-C para IA". La metáfora es exacta. USB-C no resolvió el problema de cómo cargar una laptop o cómo manejar un monitor; estandarizó el conector y el protocolo de negociación para que cualquier dispositivo pudiera conectarse a cualquier host. MCP no inventa nuevas herramientas, nuevos recursos, ni nuevos prompts; estandariza el contrato por el cual una herramienta se expone a sí misma, de modo que cualquier aplicación LLM puede conectarse a cualquier herramienta sin código a medida.

A mitad de 2026 toda plataforma LLM principal — Claude, ChatGPT, Gemini, Copilot, los frameworks LLM open-source — habla MCP nativamente. El registry oficial lista cientos de servidores en producción. Anthropic, OpenAI, Microsoft, Google y AWS mantienen librerías cliente. La spec se gobierna bajo un modelo de gobernanza abierto con Working Groups, Standards Enhancement Proposals (SEPs), y un roadmap publicado. La apuesta del día uno — que un protocolo con las primitivas correctas iba a absorber el espacio de integración de herramientas de la misma forma que HTTP absorbió el espacio de integración de documentos — aterrizó.

La arquitectura: hosts, clients, servers

MCP define tres roles. Entender la separación es la parte que carga peso de cada otra sección.

Arquitectura MCP:

  ┌──────────────────────────────────────────────────────────┐
  │  HOST  (Claude Desktop, Cursor, VS Code, tu agente)      │
  │                                                          │
  │   ┌──────────┐    ┌──────────┐    ┌──────────┐           │
  │   │ Client A │    │ Client B │    │ Client C │           │
  │   └────┬─────┘    └────┬─────┘    └────┬─────┘           │
  └────────┼───────────────┼───────────────┼─────────────────┘
           │ JSON-RPC 2.0  │ JSON-RPC 2.0  │ JSON-RPC 2.0
           ▼               ▼               ▼
       ┌─────────┐     ┌─────────┐     ┌─────────┐
       │ Server  │     │ Server  │     │ Server  │
       │ (Github)│     │ (Notion)│     │ (Postgres)
       └─────────┘     └─────────┘     └─────────┘

Un host es la aplicación LLM con la que el usuario realmente interactúa — Claude Desktop, Cursor, VS Code con una extensión MCP, un agente de Agent Builder en producción. El host es dueño de la confianza del usuario, gestiona el LLM que hace el razonamiento, y decide con qué servers el agente tiene permitido hablar.

Un client es el conector dentro del host. Hay un client por conexión a server. El client habla el protocolo MCP; no habla el lenguaje de la herramienta subyacente. Desde la perspectiva del host, cada server conectado luce de la misma forma porque cada client implementa la misma superficie de protocolo.

Un server es el servicio que expone capacidades. Un server MCP de GitHub expone la API de GitHub como primitivas MCP. Un server MCP de Postgres expone la base de datos. Un server MCP de filesystem expone los archivos locales. El autor del server escribe la traducción de pedidos con forma MCP a la API o data store subyacente. Después de eso, cualquier aplicación LLM del mundo puede usar el server a través del mismo código.

El modelo mental correcto es que el host es el director de orquesta, los clients son la técnica de los músicos, y los servers son los instrumentos. El director no necesita saber cómo está construido cada instrumento; la técnica lo encapsula. Cambiá un instrumento, y la técnica sigue funcionando.

Las seis primitivas

MCP estandariza seis primitivas divididas en dos mitades: tres que el server le ofrece al client, y tres que el client le ofrece al server. La división importa porque es la respuesta estructural a "cómo le responde una herramienta al agente".

Primitivas del server: lo que el server ofrece

Tools. Acciones ejecutables que el LLM puede decidir llamar. Una tool tiene un nombre, una descripción (que el LLM lee para decidir cuándo invocarla), y una definición de input en JSON Schema. Llamar una tool corre código del lado del server con los argumentos provistos por el LLM y devuelve un resultado. Las tools son la unidad de agencia: cualquier cosa que cambie el mundo — mandar un mail, escribir un archivo, ejecutar un query, postear una transacción — es una tool.

// Definición de tool servida por un server MCP de Postgres
{
  "name": "query",
  "description": "Correr un query SQL de solo lectura contra la base configurada. Usalo cuando el usuario pregunte sobre datos.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "sql": { "type": "string",
              "description": "Una sentencia SELECT. INSERT/UPDATE/DELETE son rechazadas." }
    },
    "required": ["sql"]
  },
  "annotations": {
    "readOnlyHint": true,
    "openWorldHint": false
  }
}

Las annotations son hints que el host usa para decidir políticas: una tool read-only puede auto-aprobarse; una tool destructiva requiere consentimiento explícito. El host trata las annotations como no confiables a menos que el server en sí sea confiable.

Resources. Datos de solo lectura que el LLM (o el usuario) puede traer al contexto. Un resource tiene una URI, un MIME type, y contenido. Los resources son la unidad de estado: cualquier cosa que existe y que el agente puede querer leer — un archivo, un documento, una fila, un resultado de búsqueda — es un resource. Los resources pueden suscribirse: el client le dice al server "avisame cuando esto cambie", y el server pushea updates sobre la misma conexión.

// Resource servido por un server MCP de filesystem
{
  "uri": "file:///workspace/contracts/lease.pdf",
  "name": "lease.pdf",
  "mimeType": "application/pdf",
  "size": 982341
}

// Suscribirse a cambios en un resource
{ "jsonrpc": "2.0", "id": 7,
  "method": "resources/subscribe",
  "params": { "uri": "file:///workspace/contracts/lease.pdf" } }

La distinción tools-vs-resources no es académica. Las tools son cómo un agente actúa; los resources son cómo un agente lee. Un server bien diseñado mantiene las dos separadas: una operación read-only vive en un resource; una operación con efectos secundarios vive en una tool. Los hosts aplican políticas de consentimiento distintas a cada una, y los operadores se apoyan en esa separación cuando alcancean qué capacidades un agente tiene permitido usar.

Prompts. Templates de mensaje reutilizables y parametrizados que el usuario (no el modelo) puede invocar. Los prompts son la unidad de workflow cara al usuario: un prompt "resumí este PR" es una invocación de un click que construye un mensaje bien-alcanzado sobre el que el LLM puede actuar. Los prompts son explícitamente iniciados por el usuario — el LLM no puede llamar un prompt — lo que los vuelve más seguros que las tools y más descubribles que los mensajes de forma libre.

// Prompt servido por un server MCP de GitHub
{
  "name": "summarize_pr",
  "description": "Resumir un pull request incluyendo el diff, los comentarios y el estado de CI.",
  "arguments": [
    { "name": "repo", "description": "owner/name", "required": true },
    { "name": "prNumber", "description": "número del PR", "required": true }
  ]
}

Primitivas del client: lo que el client ofrece

La otra mitad del protocolo es lo que el client le ofrece al server. Esta es la parte que la mayoría de las introducciones a MCP saltean; también es lo que separa a MCP de un modelo unidireccional "el agente llama tools". Los servers pueden pedirle cosas al client.

Sampling. El server puede pedirle al host que corra una llamada LLM en su nombre. El ejemplo clásico: un server MCP de GitHub encargado de "revisá este PR" puede samplear el LLM del host con el diff y un prompt de revisión, recibir de vuelta una review estructurada, y devolverla como resultado de la tool. El autor del server no tiene que shippear su propia API key del modelo, y el usuario tiene una sola superficie de consentimiento ("este server quiere hacer una llamada LLM en tu nombre, ¿lo permitís?"). El host conserva el control sobre qué modelo, qué presupuesto, y qué contenido efectivamente va al modelo.

// El server pide sampling al host
{ "jsonrpc": "2.0", "id": 11,
  "method": "sampling/createMessage",
  "params": {
    "messages": [{
      "role": "user",
      "content": { "type": "text",
                    "text": "Revisá este PR y marcá riesgos: ..." }
    }],
    "systemPrompt": "Sos un reviewer senior.",
    "maxTokens": 2000,
    "modelPreferences": { "intelligencePriority": 0.8,
                          "costPriority": 0.2 }
  } }

Roots. El server puede pedirle al host las URI o los bordes de filesystem dentro de los cuales tiene permitido operar. Un server MCP de filesystem invocado por un host no debería tener permitido leer archivos arbitrarios; el host responde a un pedido roots/list con los directorios del proyecto que el usuario consintió exponer. El server entonces restringe sus operaciones a esos roots.

Elicitation. El server puede pedirle al host que le pregunte al usuario por información adicional. El ejemplo clásico: un server que cobra pagos necesita un email para el recibo, el LLM está a mitad de conversación y no lo tiene. En lugar de inventar uno o fallar, el server emite un pedido de elicitation, el host muestra al usuario un formulario chico, el usuario lo completa, el valor se devuelve al server. Es el mecanismo a nivel protocolo que evita que el agente alucine datos del usuario.

Las tres primitivas del client juntas cierran un loop que el ecosistema temprano de agentes manejó mal. El agente llama una tool; la tool necesita más del modelo, o quiere input del usuario, o quiere saber qué archivos puede tocar. Sin primitivas de protocolo, cada server inventaba su propio canal out-of-band — variables de entorno, side servers, patrones "llamame después". Con sampling, roots y elicitation, los tres flujos pasan por la misma conexión con los mismos gates de consentimiento.

El lifecycle y el protocolo base

MCP corre sobre JSON-RPC 2.0 sobre un transport duplex. El client y el server ejecutan un handshake de tres pasos al conectarse, intercambian capabilities, y después operan como una sesión stateful de larga duración (en la spec 2025-11-25; vamos a llegar al rediseño stateless 2026-07-28).

Handshake:

  Client                          Server
  ──────                          ──────
   │                                │
   ├── initialize (capabilities) ──►│
   │◄── initialize response ────────┤
   ├── notifications/initialized ──►│
   │                                │
   │  (protocolo normal)            │
   ├── tools/list ─────────────────►│
   │◄── tool list ──────────────────┤
   ├── tools/call ────────────────►│
   │◄── tool result ────────────────┤
   │                                │

Durante initialize, ambos lados declaran qué capabilities soportan. El client dice "implemento sampling, roots y elicitation"; el server dice "expongo tools, resources y prompts, con subscripciones habilitadas en resources". La negociación permite que clients viejos se conecten a servers nuevos graciosamente — cualquier cosa que un lado no entienda, simplemente no se usa.

La misma conexión JSON-RPC después carga cada llamada de primitiva (tools/list, tools/call, resources/read, resources/subscribe, prompts/list, prompts/get, sampling/createMessage, roots/list, elicitation/create) más los métodos utilitarios (ping, cancelled, progress, logging/setLevel) hasta que un lado cierra.

Transports: stdio y Streamable HTTP

El protocolo es transport-agnostic, pero dos transports dominan en la práctica.

stdio. El host lanza al server como un proceso hijo y los dos intercambian mensajes JSON-RPC sobre stdin/stdout. Es el caso local-only: la máquina de un desarrollador corriendo un server MCP que expone el filesystem local, el repositorio git local, o un Postgres en localhost. La latencia es microsegundos, el deployment es trivial, la seguridad es la que ya tenga el borde de confianza del proceso host.

Streamable HTTP. El server corre como un servicio remoto y el host abre una conexión HTTP. La spec actual usa conexiones de larga duración con Server-Sent Events para streaming server-a-client. El release candidate 2026-07-28 reformula esto en un modelo stateless — cada request carga su propio contexto de routing, sin sticky sessions, sin header Mcp-Session-Id — lo que permite que los servers MCP corran horizontalmente detrás de un load balancer de la forma en que lo hace cualquier otro servicio HTTP.

El roadmap 2026 es explícito: no se están agregando transports oficiales nuevos en este ciclo. Los dos que existen cubren los dos casos reales (proceso local, servicio remoto); agregar un tercero fragmentaría la superficie de implementación por una ganancia marginal.

OAuth 2.1, scopes, y el stack de autorización

Para servers MCP remotos, la autorización es el problema que carga peso. La spec adopta OAuth 2.1 con PKCE, separando los roles de resource server (el server MCP en sí) y authorization server (que puede ser el mismo o un servicio distinto). El flujo es el OAuth estándar: el host redirige al usuario al authorization server, el usuario consiente, el host recibe un access token, el host lo adjunta a cada request MCP subsiguiente.

Lo que MCP agrega encima de OAuth es disciplina de scopes. Cada tool que un server expone puede declarar los scopes OAuth que requiere. La tool create_pr de un server MCP de GitHub requiere repo:write; su tool list_issues requiere solo repo:read. El host puede pedir solo los scopes que el usuario realmente necesita para el workflow a la mano, que es lo que habilita el acceso de least-privilege. Un agente que solo lee issues nunca recibe las credenciales para abrir un PR.

El release candidate 2026-07-28 agrega seis mejoras de endurecimiento OAuth. Los clients deben validar el parámetro iss según RFC 9207 (mitigando mix-up attacks). Los clients declaran application_type de OpenID Connect al registrarse. Las credenciales bindean a URLs de issuer con re-registro requerido al migrar. Los flujos de refresh-token y la acumulación de scopes en step-up authentication se clarifican. Ninguno es exótico; son el tipo de higiene OAuth que cualquier operador desplegando servers MCP remotos debería adoptar.

El release candidate 2026-07-28: qué cambia

El release candidate cerró el 21 de mayo de 2026 con la spec final aterrizando el 28 de julio de 2026. Cinco de sus cambios son lo suficientemente grandes como para nombrar.

Núcleo de protocolo stateless. El shift arquitectónico más grande en la historia de MCP. El handshake initialize desaparece del wire; Mcp-Session-Id se va. Cada request carga un header MCP-Protocol-Version y los metadata de routing que necesita (Mcp-Method, Mcp-Name) de modo que cualquier instancia de server puede manejar cualquier request. Las aplicaciones que necesiten estado — tasks de larga duración, subscripciones, contexto conversacional — adoptan el "explicit-handle pattern": el server emite un identificador en la primera llamada y el modelo lo va pasando en llamadas subsiguientes como un argumento ordinario. La ganancia es que los servers MCP ahora pueden escalar horizontalmente como cualquier otro servicio HTTP. El costo es que cada autor de server tiene que repensar cualquier cosa que antes dependiera de session affinity.

// Antes — 2025-11-25, stateful
POST /mcp
Mcp-Session-Id: 1868a90c-3a3f-4f5b
Content-Type: application/json
{"jsonrpc":"2.0","id":2,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"}}}

// Después — 2026-07-28, stateless
POST /mcp
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json
{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"}}}

MCP Apps. Los servers ahora pueden shippear interfaces HTML interactivas que el host renderea en un iframe sandboxeado. Una tool declara su template UI por adelantado para que el host pueda pre-fetchearlo y revisarlo desde el lado de seguridad. La UI rendereada habla de vuelta al host sobre la misma conexión JSON-RPC. El caso de uso es la clase entera de flujos de agente que necesitan interacción más rica que texto: mostrar un mapa para una ruta, renderear un carrito para revisión, desplegar un gráfico para una consulta financiera. Antes de MCP Apps, el server devolvía texto plano o markdown y el host tenía que adivinar cómo rendererearlo; con MCP Apps, el server controla la UI pero el host controla el sandbox.

Tasks como extensión formal. Las llamadas a tools de larga duración (cualquier cosa más allá de unos segundos) ahora usan la extensión Tasks. El flujo: tools/call devuelve un handle de task en lugar de un resultado inmediato; el client polea con tasks/get o se suscribe vía tasks/update; el client puede hacer tasks/cancel en cualquier momento. La semántica está deliberadamente alineada con el modelo de tasks de A2A (los mismos ocho estados, las mismas transiciones interrumpibles), que es la fundación para la composición MCP-A2A que usamos mucho en Agent Builder.

Routing headers. Mcp-Method y Mcp-Name le permiten a los load balancers rutear tráfico MCP sin inspeccionar payloads JSON. Esto es operacionalmente enorme para cualquiera corriendo un server MCP a escala — tu config de nginx puede rutear tools/call name=search a una flota distinta que resources/read.

Política formal de deprecación. Los features ahora siguen Active → Deprecated → Removed con una ventana mínima de 12 meses entre etapas. Roots, Sampling, y Logging entran en deprecación en 2026-07-28, reemplazados por convenciones de parámetros de tools, integración directa con APIs LLM, y stderr/OpenTelemetry respectivamente. La política de deprecación es la pieza más importante de disciplina de gobernanza que MCP agregó; les dice a los operadores que van a tener un año de aviso antes de que cualquier feature del que su server depende desaparezca.

El modelo de seguridad que la spec shippea, y lo que te deja a vos

El modelo de seguridad de MCP se estructura alrededor de cuatro principios deletreados en la spec.

Consentimiento y control del usuario. Cada acceso a datos, cada invocación de tool, cada pedido de sampling debe ser auditable y aprobable por el usuario. La spec no lo enforza a nivel protocolo — ese es el trabajo del host — pero requiere que los hosts lo implementen.

Privacidad de datos. Los hosts deben obtener consentimiento explícito antes de exponer datos del usuario a servers. Los hosts no deben retransmitir datos de resources a otros lados sin consentimiento. Es la respuesta explícita a la pregunta obvia "si mi agente puede leer mi filesystem, ¿qué impide que el vendor del agente envíe su contenido a su pipeline de analytics?". El protocolo dice: nada técnicamente los detiene, pero el modelo de consentimiento les exige pedir.

Tool safety. Las tools son ejecución arbitraria de código. El protocolo explícitamente dice que las descripciones de tools y las annotations son no confiables a menos que el server sea confiable. Un server malicioso puede mentir sobre lo que hace su tool en la descripción; el host tiene que asumir lo peor hasta que tenga razones para no hacerlo. La implicancia para los operadores es que confías en el server, no en la descripción.

Controles de sampling. El usuario debe aprobar cada pedido de sampling. El usuario controla si el sampling ocurre, el prompt real que se manda, y qué del resultado ve el server. El protocolo intencionalmente limita la visibilidad del server sobre los prompts para evitar que un server malicioso los coseche.

Lo que la spec le deja a los operadores es todo lo que está por debajo de esos principios. La spec te dice que requieras consentimiento del usuario; no te dice cómo implementar un buen UX de consentimiento. La spec te dice que alcancees tokens OAuth; no impide que tu operador otorgue repo:admin a un server que solo necesitaba repo:read. La spec te dice que trates las descripciones de tools como no confiables; no impide que te conectes a un server que encontraste en GitHub ayer sin leer qué hace realmente.

Las preocupaciones del operador que la spec no resuelve

Un operador de agentes corriendo MCP en producción tiene que resolver un conjunto chico de problemas que la spec deliberadamente deja abiertos. Nos encontramos con todos estos en nuestra propia infraestructura y son el conocimiento no escrito que separa a un operador cuya flota es durable de uno cuya flota es una responsabilidad.

Gestión de secretos. Un server MCP que habla con GitHub necesita un token de GitHub. Un server MCP que habla con Stripe necesita una API key. La tentación es meter el secreto en una variable de entorno y arrancar el server. La respuesta correcta es un manejador de secretos (Doppler, 1Password, AWS Secrets Manager, Vault) que el server lee en runtime, que rota la credencial periódicamente, y que registra cada lectura. Credenciales en texto plano de larga duración sobre disco son la causa más común de incidentes de seguridad relacionados a MCP en 2026.

Minimización de scope. Cada scope OAuth que otorgás es un radio de explosión potencial. Servers pidiendo scopes amplios ("admin", "all-repo", "read-and-write") merecen escrutinio. La disciplina que adoptan los operadores con los que trabajamos: otorgá el scope más chico que efectivamente funcione, observá el comportamiento del server por dos semanas, solo ampliá el scope si el operador choca contra un límite genuino. Leer el código fuente del server (la mayoría son open source) para verificar el scope listado como requerido es el paso que carga peso.

Observabilidad de tool-calls. Cada llamada MCP que tu agente hace debería ser logueada. Los argumentos, el resultado, la latencia, el costo. Un operador de agentes que no puede responder "¿qué tools llamó mi agente el martes entre 14:00 y 15:00?" está operando a ciegas. La spec 2026-07-28 estandariza la propagación de W3C Trace Context, lo que significa que los stacks modernos de observabilidad (Datadog, Honeycomb, colectores de OpenTelemetry) pueden correlacionar llamadas MCP en los mismos traces que todo lo demás que tu agente hace. Usalo.

Identidad y provenance del server. Un server MCP es una pieza de software corriendo en una máquina. Saber quién lo construyó, qué versión es, y que el binario que estás corriendo coincide con el código fuente que revisaste es la disciplina básica de supply-chain que el protocolo no enforza. Firmá tus contenedores de server. Pineá la versión en tu configuración de host. Vigilá el repositorio upstream por cambios no anunciados. El vector de ataque MCP más insidioso es un server que era benigno cuando lo revisaste y sobre el cual el maintainer (o quien sea que comprometió la cuenta del maintainer) shippea un update.

Consentimiento al conectar vs en runtime. Un host ingenuo le pregunta al usuario "¿permitís este server?" al momento de conectar y después corre todo sin confirmación adicional. Un host bien diseñado pregunta una vez para operaciones read-only y pregunta cada vez para operaciones annotadas como destructivas o potencialmente caras. Los operadores eligiendo un host deberían preocuparse por esta distinción; los usuarios eligiendo un operador deberían preocuparse por cuál host están operando.

Sandbox y límites de recursos. Un server MCP que puede ejecutar código arbitrario (un server de Python, un server de shell, un server de tool arbitraria) debería correr en un sandbox con límites de CPU, memoria y red. Las microVMs de Firecracker (que cubrimos en nuestro post de microVM) son la primitiva correcta. Un server portándose mal que quema 100% de CPU durante una hora es un server portándose mal; un server portándose mal que escapa del sandbox es un host comprometido. La diferencia son los límites que pusiste antes del mal día.

Composición con A2A y el resto del stack

MCP es la capa vertical del stack agéntico — agente a herramientas. La capa horizontal, agente a agente, es A2A. Las dos componen en un patrón limpio: un agente usa MCP para interactuar con sus propias herramientas y consume A2A para delegar trabajo a otros agentes.

Patrón de composición en producción:

  ┌──── Tu agente ─────┐
  │                    │
  │   ▲ A2A ◄──────────┼── otro agente
  │   │                │
  │   │  MCP (tools)   │
  │   ▼                │
  │  ┌──┐  ┌──┐  ┌──┐  │
  │  │GH│  │DB│  │FS│  │  ← servers MCP
  │  └──┘  └──┘  └──┘  │
  └────────────────────┘

Desde adentro de la perspectiva del agente, MCP es cómo alcanza sus propias herramientas y recursos; A2A es cómo alcanza otros agentes. El deployment de producción de PayPal es el ejemplo canónico: un sales agent del lado del comprador habla A2A con el agente de facturación hosteado por PayPal, que internamente habla MCP con los sistemas de billing subyacentes de PayPal. El agente del comprador nunca toca el server MCP de PayPal — ese borde es propiedad de PayPal — pero igual puede delegar trabajo dentro del territorio de PayPal porque ambos lados hablan A2A.

La misma composición con AP2 mete pagos encima: una llamada a tool MCP que cuesta plata emite un Cart Mandate; el usuario (o la autorización delegada del usuario) lo firma; el Payment Mandate fluye a través de x402 o un rail de tarjeta; el resultado de la llamada a la tool aterriza. La composición se lee de abajo hacia arriba: x402/AP2 para pago, MCP para el trabajo real, A2A para la coordinación cross-agente, ERC-8004 para la identidad que permite que todos confíen entre sí.

Cómo Agent Builder cablea MCP por vos

El reconocimiento honesto: la mayoría de los operadores no quieren implementar MCP. Quieren que su agente tenga acceso a GitHub sin escribir un server, acceso a Postgres sin configurar OAuth, acceso a Notion sin gestionar tokens. Agent Builder es lo que hace eso posible.

Tres cosas concretas que Agent Builder hace sobre MCP.

El catálogo de servers pre-conectados. Elegí del catálogo — GitHub, Notion, Postgres, Stripe, Slack, Linear, Postgres, Google Drive, S3, búsqueda web, browse web, filesystem, shell, python — y un server queda aprovisionado para tu agente. El flujo OAuth se inicia cuando te conectás; los tokens se guardan en el secret store; los scopes se minimizan a lo que el workflow que describiste realmente necesita. No escribiste ningún código MCP; usaste el protocolo.

Topes de scope y rate por agente. Cada agente en tu flota recibe su propio client MCP con sus propios scopes otorgados y su propio presupuesto diario de llamadas. Un agente que solo debería leer tu inbox no puede llamar tools send, incluso si el server subyacente las expone. Un agente que se porta mal y empieza a loopear en una tool choca con el rate cap y se detiene antes de drenar nada. El tope es configurable por tool; vienen defaults razonables en las entradas del catálogo.

Superficie completa de observabilidad. Cada llamada MCP que tu agente hace aparece en el dashboard del operador: qué tool, qué argumentos, qué resultado, cuánto tardó, cuánto costó. Las fallas se categorizan. El costo en el tiempo se grafica. La propagación de W3C Trace Context del 2026-07-28 está habilitada por defecto, de modo que si shippeás traces a tu propio backend, el tráfico MCP correlaciona con todo lo demás.

BYO server. Los operadores que quieran exponer una API interna a sus agentes — un CRM privado, una base de datos custom, un servicio propietario de scoring — apuntan Agent Builder a un server MCP self-hosted y se une al catálogo como cualquier otro. La misma disciplina de scopes, rate caps y observabilidad aplica. Escribís el server una vez; cada agente en tu flota puede usarlo.

Consejos prácticos para el operador leyendo esto un lunes

La versión más corta de "cómo empezar con MCP" que podemos meter en un párrafo: instalá un host capaz de MCP (Claude Desktop es gratuito, Cursor es el dev-friendly, Agent Builder es el operator-friendly); conectá tres servers (filesystem para trabajo local, GitHub o Linear para estado del proyecto, un server de búsqueda para contexto web); hacé diez llamadas a tools; leé los transcripts; fijate qué hizo bien el modelo y qué hizo mal. Para el final de una mañana de trabajo tenés la intuición del protocolo, y la intuición es sobre la que se apoyan todos los temas más avanzados de este post.

La versión más larga es una secuencia que vimos pasar productivamente a docenas de operadores.

Leé el código fuente de tres servers antes de confiar en ellos. No el README; el código. Mirá qué scopes pide el server, qué hacen las tools efectivamente, qué cubren las URIs de los resources. Es la forma más barata de aprender la forma de un server MCP real y la más confiable de desarrollar el feeling para qué servers de terceros vale la pena instalar.

Escribí un server chiquito. Elegí algo que ya automatizás con un shell script o un programa Python chico — un reporte diario, un convertidor CSV, un llamado a una API interna. Envolvelo como un server MCP. El ejercicio de declarar un schema de input, decidir qué es tool vs qué es resource, y escribir las annotations apropiadas de consentimiento es el camino más rápido para entender por qué el protocolo tomó las decisiones que tomó.

Enchufá observabilidad antes de tu primer agente en producción. Gasto de tokens, rate de tool-calls, rate de excepciones, latencia p95. La versión de cinco minutos es el dashboard built-in de Agent Builder; la versión de producción es shippear los traces a la observabilidad que ya operás. El punto es que no deberías correr un agente que use MCP en producción sin poder responder "qué hizo".

Adoptá la política de deprecación en tu propio server. Si shippeás un server que otros agentes van a usar, seguí la misma disciplina Active → Deprecated → Removed que la spec adopta. Tus consumidores downstream dependen de una superficie estable; los cambios breaking sin aviso son cómo mueren los ecosistemas de servers.

Tratá la seguridad como una partida presupuestaria, no como un afterthought. Los manejadores de secretos cuestan plata; los sandboxes cuestan cómputo; la observabilidad cuesta storage. Todos cuestan menos que el incidente que hubieran evitado. Los operadores serios sobre este trabajo asignan dos horas por semana a revisar logs y una hora por mes a revisar grants de scope. El retorno compuesto es enorme.

Cierre

MCP es el protocolo que diseñarías si te sentaras un lunes y preguntaras "cuál es la forma del contrato que toda aplicación LLM necesitaría con toda herramienta, si lo hiciéramos una vez y solo una vez". Anthropic hizo esa pregunta a fines de 2024; a mitad de 2026, toda plataforma principal, todo framework, todo stack de tools cara al operador convergió en la respuesta. La especificación 2025-11-25 es la superficie estable que la mayoría de los operadores está corriendo hoy; el release candidate 2026-07-28 es la reescritura que vuelve al protocolo grado-producción para escala (transport stateless, MCP Apps, Tasks como extensión formal, seis propuestas de endurecimiento OAuth).

Para un operador leyendo esto con una flota de agentes que correr, las conclusiones prácticas son cortas. Elegí un host que tome el consentimiento en serio. Conectá el conjunto más chico de servers que tus agentes realmente necesiten. Leé el código de los servers que no escribís vos. Enchufá observabilidad antes de escalar. Tratá secretos, scopes y sandboxes como infraestructura durable, no como setup de una sola vez.

Para un operador leyendo esto que todavía no arrancó, la conclusión práctica es todavía más corta. Instalá un host, conectá tres servers, hacé diez llamadas a tools, leé los transcripts. Para el miércoles vas a saber más sobre cómo funcionan los agentes en realidad que el 90% de la gente que escribe sobre ellos.

La spec está en modelcontextprotocol.io. Las implementaciones de referencia están en github.com/modelcontextprotocol. El catálogo MCP de Agent Builder está en llm4agents.com. El protocolo es la única pieza del stack agéntico que un operador puede adoptar hoy, en producción, sin dejar atrás decisiones propensas a arrepentimiento.