MCP explicado: herramientas para agentes y la propuesta WebMCP

Tu asistente puede razonar sobre un pedido, pero no sabe si el pedido 4312 ya fue enviado. Para responder necesita hablar con la fuente de verdad; no basta con pegarle una captura de pantalla ni con prometerle «acceso a todo». MCP (Model Context Protocol) define una forma de descubrir capacidades y solicitar datos o acciones a sistemas externos.

Qué problema resuelve y qué NO resuelve

Sin un contrato común, cada aplicación de IA necesita una integración distinta para consultar un servicio, leer un documento o ejecutar una acción. MCP separa al host (la aplicación que usa el modelo), su cliente MCP (la conexión) y el servidor MCP (quien ofrece capacidades). Es como un enchufe definido para conectar piezas, no una garantía de que cualquier pieza sea segura o correcta.

El protocolo no elige tu modelo, no le concede permiso ilimitado y no decide cuándo se debe confirmar una operación. Esas decisiones siguen siendo responsabilidad de tu aplicación, su política de acceso y la persona usuaria.

Un servidor puede ofrecer tres primitivas principales:

• Tools: funciones ejecutables; por ejemplo, buscar_pedido o crear_ticket. Sus parámetros describen qué se puede enviar. Una tool puede tener efectos secundarios.
• Resources: datos que sirven como contexto, como el esquema de una API o un documento. Leer una resource no equivale a editarla.
• Prompts: plantillas reutilizables que guían una interacción; no son llamadas a una API por sí solas.

Consejo: empieza con una tool de solo lectura y un alcance pequeño. Es más fácil explicar y probar «consultar un pedido autorizado» que «administrar todos los pedidos».

El recorrido de una consulta real

Imagina que el usuario pregunta: «¿Dónde está mi pedido?». El host conecta con el servidor MCP, descubre buscar_pedido, ofrece esa descripción al modelo, valida argumentos y solicita la ejecución. El servidor consulta el sistema de pedidos con la identidad y permisos correctos y devuelve un resultado. Finalmente, el asistente lo interpreta. Si un pedido no pertenece a esa persona, el servidor debe rechazarlo aunque el modelo pida consultarlo.

Una definición conceptual de la tool podría verse así; es un contrato ilustrativo, no un servidor MCP completo ni un paquete que debas instalar:

{
  "name": "buscar_pedido",
  "description": "Devuelve el estado de un pedido visible para la sesión actual",
  "inputSchema": {
    "type": "object",
    "properties": { "orderId": { "type": "string" } },
    "required": ["orderId"]
  }
}

La descripción ayuda a decidir cuándo llamar la tool; el esquema indica cómo llamarla. Ninguno sustituye la verificación en el backend:

// Lógica de aplicación detrás de una tool; el SDK MCP maneja el protocolo.
async function buscarPedido(orderId: string, userId: string) {
  if (!/^[0-9]{1,12}$/.test(orderId)) throw new Error("ID inválido");
  const pedido = await db.orders.findById(orderId);
  if (!pedido || pedido.ownerId !== userId) return { encontrado: false };
  return { encontrado: true, estado: pedido.status };
}

userId viene de la sesión validada, no de una respuesta generada por el modelo. Ese detalle separa una demo vistosa de una integración que puede entrar en producción. Para ejecutar la integración real usa un SDK y la versión del protocolo compatibles con tu host; las formas de inicialización y transporte evolucionan.

Local, remoto y límites de confianza

Un servidor local suele comunicarse por stdio con un cliente en la misma máquina. Uno remoto usa Streamable HTTP y necesita autenticación y controles de red apropiados. En ambos casos, trata los resultados de herramientas, documentos y descripciones como datos potencialmente no confiables: pueden contener instrucciones maliciosas (prompt injection) que no deben convertirse en órdenes del sistema.

Registra qué tool se invocó y con qué resultado, pero no almacenes secretos ni datos sensibles sin motivo. Para acciones como borrar, comprar o enviar, exige confirmación humana y aplica autorización en el servidor. «La IA lo pidió» nunca debe ser un permiso.

¿Y WebMCP? El navegador entra en escena

WebMCP es un borrador de grupo comunitario, no un estándar W3C final ni una API disponible por defecto en todos los navegadores. Su idea es que una página exponga funciones JavaScript como herramientas para agentes que interactúan con esa misma interfaz. A diferencia de un servidor MCP remoto, la función vive en el contexto de la página y puede usar su estado y sus flujos ya existentes.

El borrador describe document.modelContext.registerTool. Este ejemplo es experimental e ilustrativo; comprueba soporte y consulta la versión de la propuesta antes de usarlo:

if ("modelContext" in document) {
  await document.modelContext.registerTool({
    name: "consultar_carrito",
    description: "Resume el carrito que la persona está viendo",
    inputSchema: { type: "object", properties: {} },
    execute: async () => ({ items: cart.items.length, total: cart.total }),
  });
}

Este ejemplo no hace que WebMCP funcione en navegadores sin implementación. Tampoco expone automáticamente el carrito a todos los orígenes: permisos, contexto y políticas de seguridad importan. El modelo de ejecución y la API aún pueden cambiar. WebMCP no reemplaza el MCP de backend cuando necesitas acceso seguro a bases de datos, tareas de servidor o credenciales.

Cuándo elegir cada pieza

Usa un skill cuando el agente necesita saber cómo trabajar (un procedimiento); un servidor MCP cuando necesita obtener datos o ejecutar acciones a través de un límite claro; y considera WebMCP si necesitas conectar agentes con funcionalidades de una web en un entorno que soporte esta propuesta. Mantén las operaciones privilegiadas en el servidor y empieza por lecturas verificables.

Si vas a construir algo hoy, prueba primero una tool de consulta con permisos reales, casos de error y logs útiles. La mejor integración no es la que expone más funciones, sino la que permite responder una pregunta correcta sin conceder más acceso del necesario.

Fuentes: Arquitectura MCP · Especificación MCP · Borrador WebMCP.