Conectar N herramientas con M modelos antes exigía N×M capas de adaptación. MCP desacopla el lado de las herramientas del lado de los modelos para que cada uno implemente el protocolo una sola vez. Aquí se explican esa decisión de diseño, la abstracción de entornos y acciones del navegador y los problemas que aún no resuelve.
Para que un Agent haga trabajo real, casi siempre termina actuando en un navegador: iniciar sesión, publicar, recopilar datos o rellenar formularios. La dificultad técnica no está en si puede hacer clic, sino en el coste de integración de poner un navegador en manos del Agent.
El laberinto de adaptaciones N×M
Supongamos que hay N herramientas y M modelos en el mercado. El proveedor de cada herramienta debe escribir una integración para cada modelo, y el lado del modelo necesita una capa de adaptación para cada herramienta. Ambos mantienen sus propias implementaciones, con un total de N×M.
El problema es que se trata de una multiplicación. Añadir una herramienta no implica una sola tarea más: hay que conectarla con cada modelo. A la inversa, cuando cambia la versión de un modelo, quizá haya que volver a validar herramientas ya integradas. Una capacidad puede estar muy bien diseñada, pero si no existe una adaptación para un modelo concreto, no puede utilizarse allí: la herramienta queda atascada en la capa de distribución.
Al principio, cada parte tenía que construir su propia solución. Para hacer lo mismo —listar entornos, iniciar un navegador o leer una página— había que reescribir la integración al cambiar de consumidor, y la lógica solía divergir: unos implementaban las esperas en el cliente y otros en el servidor.
El protocolo desacopla ambos lados
MCP (Model Context Protocol) se hizo público a finales de 2024. Su enfoque consiste en definir en un formato estándar el descubrimiento y la invocación de herramientas: qué se expone, cómo se describen los parámetros y qué estructura se devuelve.
La arquitectura pasa entonces a ser un Agent conectado a un MCP Client, que a su vez conecta con varios MCP Server según el protocolo; las capacidades concretas quedan detrás de esos servidores. El esfuerzo de implementación baja de N×M a N+M: el lado del modelo implementa el cliente una vez y el lado de la herramienta implementa el servidor una vez.
Solo hay tres roles. El Host es la aplicación que ejecuta el modelo y se encarga de iniciar el cliente. El Client es la implementación del cliente del protocolo, normalmente uno por Server. El Server lo desarrolla el proveedor de la herramienta y expone sus capacidades como herramientas estandarizadas.
Actualmente hay dos modos de comunicación. El modo local utiliza entrada y salida estándar, con cliente y servidor en la misma máquina; la ruta es corta y requiere poca configuración, por eso se usa mucho en automatización. El modo remoto utiliza HTTP o WebSocket y encaja mejor en despliegues distribuidos, a cambio de tener que definir con más cuidado la autenticación y los límites de red.
En el navegador se exponen tres capas
Cuando un entorno de navegador se integra en el protocolo, las capacidades expuestas se pueden agrupar aproximadamente en tres capas.
La capa superior es el entorno: listar los entornos de una cuenta, crear uno según una configuración, iniciar uno concreto, asociarle una salida de red y cerrarlo al terminar. Antes estas operaciones estaban repartidas entre distintas APIs; ahora son herramientas que el modelo puede descubrir e invocar. Al iniciar un entorno suele devolverse un endpoint de depuración, como un puerto o una dirección WebSocket, que puede entregarse a controladores como Selenium o Puppeteer.
La capa intermedia es la página: abrir una dirección, leer el DOM o el árbol de accesibilidad, cambiar de pestaña y hacer capturas de pantalla.
La capa inferior son las acciones: hacer clic, escribir, desplazarse, esperar a que se cumpla una condición y gestionar ventanas emergentes.
El cambio clave no es cuántas acciones existen, sino que el entorno pasa de ser código que uno debe escribir a convertirse en un recurso que el Agent puede elegir y usar. Solo hay que expresar el objetivo; el Agent puede decidir si crea un entorno nuevo o reutiliza uno existente y en qué orden llama a las herramientas. Esto se nota especialmente cuando hay varios entornos en paralelo: la planificación se describe en el prompt en lugar de quedar codificada de forma rígida en un script.
Lo que todavía no está resuelto
El protocolo resuelve la conexión, no la corrección. Quedan varios aspectos fáciles de pasar por alto.
La calidad de la descripción de las herramientas determina el resultado de las llamadas. Si los parámetros son incorrectos o se elige la herramienta equivocada, el protocolo no puede solucionarlo. Además, cuando aumenta el número de herramientas, sus descripciones ocupan contexto, por lo que hay que equilibrar cantidad y granularidad. Si la granularidad es demasiado gruesa, el modelo no sabe cuántas tareas cubre una herramienta; si es demasiado fina, el contexto se llena antes.
Los permisos y la auditoría aún están en una fase temprana. Muchos servidores funcionan localmente en una sola máquina, arrancan con privilegios considerables y carecen de autorización granular y registros detallados de llamadas. En modo remoto primero hay que responder quién puede conectarse y qué puede ver.
La inestabilidad de las páginas tampoco desaparece. Elementos que no se localizan, tiempos de carga irregulares, sesiones caducadas y CAPTCHAs siguen exigiendo esperas, reintentos y mecanismos alternativos. El protocolo solo estandariza el punto de entrada.
La madurez del ecosistema también es desigual. Los distintos servidores no coinciden por completo en tipos de recursos compatibles, estructuras de respuesta o códigos de error. Al combinar varios servidores en una tarea, la lógica de orquestación suele tener que escribirse manualmente. El protocolo continúa evolucionando, así que conviene vigilar las diferencias de comportamiento entre versiones.
También hay que mantener clara otra frontera: el protocolo define cómo un modelo invoca herramientas, no si la tarea en sí cumple las normas. Si la recopilación cuenta con autorización, si el propósito de uso de una cuenta es legítimo o si se incumplen reglas de una plataforma son evaluaciones independientes y no dependen de lo fluida que sea la conexión.
En escenarios con múltiples entornos, el aislamiento entre ellos y la configuración coordinada de salida de red, zona horaria e idioma suelen afectar más al resultado que el método de integración. En la capa de aislamiento de entornos, PurpleMark ofrece interfaces de creación, inicio y configuración de red que pueden ser invocadas por herramientas de AI y coordinadas desde un mismo cliente.
Este contenido explica únicamente principios técnicos. Utiliza los protocolos y herramientas correspondientes dentro del marco legal y normativo aplicable.
