Model Context Protocol (MCP) está generando mucho entusiasmo. Es una especificación simple y elegante que facilita exponer funcionalidades y datos contextuales a modelos de AI de forma estructurada.

¿Quieres crear issues en GitHub o enviar correos a stakeholders solo preguntándole a tu editor de código? Funciona genial,en local.

MCP habilita casos de uso interesantes en tu máquina local hoy mismo. Pero ¿qué pasa si estás construyendo algo en la nube? ¿Si tu agente corre en un navegador, en un servidor o en una función cloud?

Ahí se complica todo.

El uso de MCP es mayormente local

Hoy, casi todo el ecosistema MCP es solo local. Hay una razón: el diseño original del protocolo nació para resolver un problema de integración en apps de escritorio.

La primera revisión del spec incluyó dos transportes:

  • stdio, que es perfecto para apps locales como los IDEs
  • HTTP Server-Sent Events (SSE), pensado para soportar escenarios remotos

Pero el transporte basado en SSE introdujo mucha complejidad. Requería una conexión persistente o semipersistente entre el cliente y servidor MCP, algo difícil de lograr en entornos cloud. Hay que gestionar conexiones de larga duración a través de NATs, firewalls y posiblemente contenedores efímeros.

¿El resultado? La mayoría de los servidores MCP hoy son procesos locales, y los clientes MCP asumen que hablan con un servidor en la misma máquina.

Lo que los agentes cloud necesitan

Cada vez más desarrolladores construyen agentes en la nube. Los agentes cloud suelen modelarse como microservicios: se activan vía HTTP o como parte de un sistema mayor, y se espera que manejen solicitudes de muchos usuarios.

Para que MCP funcione en ese mundo, necesitamos tres cosas:

  1. Un transporte HTTPque funcione bien para casos de solicitud/respuesta en streaming sin requerir necesariamente una conexión persistente.
  2. Un mecanismo de autorización a nivel de protocoloidealmente basado en OAuth o algo similar.
  3. , soporte para acceso delegadopara que los servidores MCP puedan llamar APIs externas en nombre del usuario.

¿La buena noticia?Elnuevo transporte HTTP ya está listo. Es amigable para la web y familiar para desarrolladores acostumbrados a hacer GETs y POSTs con payloads JSON. Plataformas de hospedaje comoCloudFlareya están trabajando para soportar el nuevo transporte en sus SDKs.

Es un gran paso hacia hacer MCP listo para agentes.

Autorización: próximamente

En tu laptop, la autorización es fácil: si un servidor MCP está corriendo, el usuario ya lo ha confiado implícitamente. Pero en la nube,necesitas una forma de autorizar la solicitud. ¿Quién hace esta llamada? ¿Tiene permiso?

Originalmente el protocolo no abordaba estas preguntas, pero eso está cambiando rápido:

  • La revisión del protocolo `2025-03-26` describióel inicio de un spec de autorización para MCP.
  • Una propuesta para clarificar la autorización entre clientes y servidores MCP está en revisión, con aportaciones de expertos en seguridad de Microsoft, Google, Arcade.dev (incluido quien escribe esto), Okta, AWS, Stytch y más.
  • Con base en esa discusión, se planea un seguimiento sobre autorización específica por herramienta.

Cuando todo eso se asiente, estas adiciones al spec de MCP abrirán el acceso seguro y composable a herramientas para agentes en cualquier lugar.

Muévete rápido, prueba cosas

Buena noticia: no tienes que esperar a que todas las piezas encajen. En Arcade.dev estamos construyendo una plataforma de integración universal para agentes y apps de AI, con cientos de herramientas ya disponibles. Eso significa que puedes empezar a construir agentes en la nube que usen esas herramientas hoy (y herramientas MCP mañana), todo con unas pocas líneas de código.

¿Quieres probar Arcade.dev?Regístrate con una cuenta gratisy cuéntanos qué piensas.