La prueba de Simon en Anthropic expone la fricción tras las conexiones MCP personalizadas

El observador de Anthropic Simon Willison conectó un servidor MCP personalizado a Claude y ChatGPT, pero el experimento reveló dos rutas de configuración muy distintas. Su prueba del 29 de julio mostró que las interfaces de chat estándar pueden utilizar herramientas creadas por desarrolladores, pese a las restricciones de producto, los requisitos de alojamiento remoto y el trabajo de autorización.

El experimento anthropic simon importa porque Model Context Protocol está trascendiendo los agentes de programación y los archivos de configuración de escritorio. MCP, un protocolo abierto para conectar aplicaciones de IA con herramientas y datos externos, está llegando a las ventanas de chat de uso cotidiano. Esto amplía su audiencia, al tiempo que hace más difíciles de ignorar las restricciones a nivel de producto.

Claude presenta la conexión como un conector personalizado. ChatGPT sitúa una funcionalidad comparable detrás de su sistema de apps y controles para desarrolladores. Ambos pueden acceder a un servidor remoto, aunque ninguno convierte ese servidor en un complemento universalmente portable. El protocolo estandariza la comunicación, mientras cada host sigue controlando el descubrimiento, los permisos, las aprobaciones y la disponibilidad.

Qué cambió realmente con la prueba MCP de Simon Willison

Un servidor MCP personalizado ahora puede atender tanto a Claude como a ChatGPT sin exigir que los usuarios abandonen sus conversaciones web habituales.

Willison documentó el proceso en una prueba MCP personalizada publicada el 29 de julio de 2026. El resultado central fue sencillo. Un desarrollador puede alojar un servidor MCP, registrarlo en ambos servicios y exponer sus herramientas dentro de sus interfaces de chat habituales.

Este resultado distingue el experimento de demostraciones anteriores de MCP centradas en Claude Code, archivos de configuración de escritorio o clientes orientados a desarrolladores. Esos entornos ya hacían relativamente natural la conexión de herramientas. Los productos de chat estándar para consumidores aplican otra capa de reglas de cuenta y controles de interfaz.

El servidor debe ser accesible de forma remota. Un proceso local que utiliza el transporte estándar de entrada y salida no puede aparecer sin más dentro de una sesión del navegador. El host necesita un endpoint HTTP accesible desde internet que implemente las partes de MCP que espera cada cliente.

El acceso remoto cambia el modelo de despliegue. Un desarrollador ya no configura una aplicación para iniciar un proceso de confianza en un ordenador personal. Está operando un servicio de red que debe gestionar la seguridad del transporte, la identidad, la autorización, la disponibilidad y, potencialmente, a múltiples usuarios.

Claude describe estas integraciones como conectores personalizados. Anthropic afirma que pueden conectar Claude con herramientas y fuentes de datos alojadas mediante servidores MCP remotos. Su actual guía sobre conectores enumera compatibilidad con Claude y Claude Desktop para cuentas individuales y laborales elegibles.

ChatGPT describe esta misma capacidad general mediante apps personalizadas y conectores MCP. La interfaz de OpenAI también distingue entre crear una app, probarla, aprobarla y ponerla a disposición dentro de un espacio de trabajo.

Esa diferencia de nomenclatura es más que cosmética. “Conector” sugiere un puente hacia un servicio existente. “App” sugiere algo empaquetado, revisado y distribuido a través de una superficie de producto controlada por el host. MCP puede admitir ambos modelos, pero las etiquetas moldean las expectativas de los usuarios.

El servidor también necesita definiciones de herramientas útiles. Esas descripciones indican al modelo qué hace cada herramienta, cuándo debe llamarse y qué entradas acepta. Un endpoint técnicamente válido puede seguir funcionando mal cuando sus herramientas se solapan o emplean descripciones imprecisas.

Por tanto, la prueba de Willison demostró interoperabilidad en la capa de protocolo, no un comportamiento idéntico entre productos. Claude y ChatGPT pueden descubrir las mismas capacidades básicas. Aun así, pueden seleccionar herramientas de forma distinta, solicitar aprobaciones diferentes y presentar resultados mediante interfaces distintas.

Para los desarrolladores, el hecho memorable no es que ambas empresas admitan MCP de alguna forma. El cambio importante es que una implementación alojada ahora puede llegar a usuarios dentro de ambos productos de chat principales. Esto hace práctica la prueba entre productos sin mantener dos protocolos de integración completamente separados.

Por qué el resultado de Anthropic Simon presiona a ambas plataformas de IA

MCP desplaza parte de la competencia desde la inteligencia de los modelos hacia el control de herramientas, permisos y distribución.

El resultado anthropic simon presiona a Anthropic porque creó MCP y ha promovido el protocolo como un estándar abierto. Claude debe seguir siendo un cliente de referencia convincente. Si los servidores externos funcionan de manera más predecible en otros lugares, la autoría del protocolo no garantizará la preferencia de la plataforma.

OpenAI enfrenta la presión opuesta. No originó MCP, pero ChatGPT desempeña un papel enorme como plataforma de aplicaciones. Los desarrolladores esperarán que admita integraciones que ya funcionan con Claude y otros clientes MCP.

Esto genera una clara tensión entre la portabilidad del protocolo y el control de la plataforma. Los desarrolladores quieren describir una herramienta una vez y conectarla en productos compatibles. Los operadores de plataformas quieren decidir qué cuentas pueden conectar servidores, qué acciones se permiten y cómo se revisan las llamadas riesgosas.

Claude ofrece actualmente un concepto directo de conector personalizado para varios tipos de cuentas. El uso en el lugar de trabajo introduce controles administrativos porque un conector puede exponer datos de la empresa o ejecutar acciones. Un propietario puede configurar la disponibilidad, mientras los usuarios individuales siguen autenticándose con sus propios permisos.

ChatGPT aplica una estructura de despliegue más explícita. La actual guía del modo desarrollador de OpenAI indica que el soporte MCP completo está disponible en la web para clientes Business y Enterprise o Edu. También describe un acceso más limitado de lectura y obtención de datos para usuarios Pro.

La distinción cobra importancia cuando un servidor expone operaciones de escritura. Buscar en una colección de documentos implica un perfil de riesgo. Actualizar registros de clientes, publicar contenido o eliminar un proyecto implica otro.

OpenAI afirma que las acciones de escritura y modificación pueden activar una confirmación, según el permiso, el contexto y el impacto potencial. Algunas acciones especialmente riesgosas pueden bloquearse. Los administradores de espacios de trabajo también controlan si una app pasa de las pruebas privadas a la disponibilidad aprobada.

Anthropic aconseja de forma similar a los usuarios que revisen las solicitudes de herramientas y habiliten únicamente las herramientas relevantes para una conversación. Su advertencia refleja una limitación básica de las interfaces agénticas. Una solicitud en lenguaje natural no siempre revela cada acción externa que un modelo podría considerar necesaria.

Estos controles debilitan la promesa más simple de portabilidad. Un desarrollador puede reutilizar el servidor, los esquemas y la base de autorización. No puede asumir coincidencias en el acceso, los flujos de usuario, el comportamiento de confirmación o las decisiones del modelo.

Esta fragmentación no implica necesariamente un fallo del protocolo. MCP define un lenguaje compartido entre clientes y servidores. No exige que cada host adopte las mismas políticas de producto.

Aun así, la fricción del producto puede determinar si la compatibilidad del protocolo importa en la práctica. Una conexión oculta tras configuraciones de administrador llegará a menos usuarios que otra disponible desde una pantalla de ajustes personales. Una implementación de solo lectura no puede sustituir a un competidor que permite escrituras cuidadosamente aprobadas.

La calidad de invocación de herramientas añade otra fuente de presión. El modelo debe elegir la herramienta correcta, generar argumentos válidos, interpretar errores y comunicar resultados. Admitir un transporte MCP no garantiza la finalización fiable de la tarea del usuario.

Por ello, los desarrolladores deberían probar los mismos prompts en ambas plataformas. Un servidor puede exponer herramientas idénticas y, aun así, producir patrones de llamadas distintos. Estas diferencias pueden revelar si una descripción es ambigua o si un host aplica controles más estrictos.

La cuestión competitiva más amplia ya no es si Claude o ChatGPT pueden llamar a una API. Ambas plataformas pueden hacerlo. La cuestión es cuál hace que las capacidades externas sean comprensibles, gobernables y fiables para los usuarios comunes.

Un protocolo sigue generando dos experiencias de configuración

MCP reduce el código de integración duplicado, pero no elimina los pasos operativos que rodean una conexión segura.

Para Claude, la ruta básica pasa por Settings y Connectors. Un usuario añade un conector personalizado, proporciona la dirección del servidor remoto y completa la autenticación cuando el servidor la requiere. Es posible que los propietarios de entornos de trabajo deban habilitar o configurar primero el conector.

La documentación de servidores de Anthropic orienta a los desarrolladores hacia la especificación de autorización del protocolo y ejemplos oficiales de SDK. También señala la compatibilidad con los patrones actuales de autorización remota.

Para ChatGPT, la ruta pasa por Apps y la configuración avanzada. El usuario o administrador habilita el acceso para desarrolladores, crea una app, introduce la URL remota de MCP, elige la autenticación y acepta la advertencia asociada con un servidor personalizado.

Los administradores de espacios de trabajo Business pueden crear y desplegar apps para su espacio de trabajo. Los entornos Enterprise y Edu añaden controles basados en roles para desarrolladores y usuarios. Estas reglas convierten la conexión en parte de la gobernanza organizativa, no meramente de una configuración personal.

El núcleo técnico compartido es un endpoint MCP remoto. Los servidores remotos modernos suelen utilizar Streamable HTTP, un transporte que lleva mensajes MCP mediante solicitudes HTTP y respuestas en streaming. Ese endpoint debe admitir los intercambios de inicialización y descubrimiento de herramientas que esperan los clientes compatibles.

Los mensajes MCP utilizan JSON-RPC 2.0, un formato estructurado para solicitudes, resultados, notificaciones y errores. El protocolo define cómo un cliente descubre herramientas y las invoca. No define la lógica de negocio subyacente de cada herramienta.

Pensemos en un servidor privado de investigación. Podría ofrecer una herramienta para buscar documentos almacenados y otra para recuperar un registro completo. Claude y ChatGPT pueden descubrir esas definiciones desde el mismo endpoint.

El desarrollador todavía debe decidir quién puede buscar en qué registros. Esa decisión corresponde al servidor y a su capa de autorización. Ocultar una herramienta en la interfaz de un cliente no sustituye la aplicación del control de acceso en la fuente de datos.

OAuth se vuelve central cuando el servidor maneja datos específicos de usuarios. El cliente guía al usuario a través de un flujo de autorización, recibe un token de acceso y presenta ese token al llamar al servidor MCP protegido. El servidor valida entonces el token antes de devolver los datos.

La especificación de autorización de MCP exige metadatos de recursos protegidos para despliegues compatibles con autorización HTTP. Esos metadatos indican a un cliente dónde se encuentran los servicios de autorización. Facilitan el descubrimiento sin codificar de forma rígida cada emparejamiento entre cliente y servidor.

Aquí es donde una prueba rápida se convierte en un proyecto de ingeniería real. El servidor necesita una dirección HTTPS estable, metadatos correctos, gestión de redirecciones, validación de tokens y ámbitos adecuados. También necesita mensajes de error que los clientes puedan interpretar cuando falle la autorización.

El registro de clientes puede crear otro problema de compatibilidad. Algunos sistemas admiten el registro dinámico o documentos de metadatos de cliente. Otros esperan un identificador de cliente creado de antemano. Un servidor diseñado en torno a una suposición podría necesitar adaptaciones antes de que ambos productos de chat se autentiquen correctamente.

Una implementación práctica debería comenzar con una herramienta limitada y de solo lectura. Por ejemplo, un equipo podría exponer notas de proyecto aprobadas mediante una única función de búsqueda. Los usuarios podrían pedir a cualquiera de los asistentes que encuentre decisiones anteriores sin conceder permisos de actualización o eliminación.

Ese caso de uso también crea un puente natural hacia una base de conocimientos personal o de equipo. MCP puede proporcionar la capa de acceso, mientras que el sistema subyacente sigue siendo responsable de la indexación, los permisos, la retención y la calidad de las fuentes.

Una vez que funcione la ruta de lectura, los desarrolladores pueden añadir acciones más precisas. Cada herramienta de escritura debería tener un propósito evidente y un alcance limitado. “Actualizar el estado de una tarea” es más fácil de revisar que “ejecutar una operación arbitraria del proyecto”.

Las descripciones de las herramientas merecen el mismo cuidado que un contrato de API. El modelo ve esas descripciones al decidir si llama a una función. Los nombres vagos aumentan la probabilidad de una selección incorrecta, llamadas repetidas o acceso innecesario a datos.

Los esquemas de entrada también deberían rechazar la ambigüedad. Una herramienta que modifica una cuenta debería requerir un identificador de cuenta estable. No debería depender únicamente del nombre de un cliente que podría coincidir con varios registros.

Las respuestas deberían devolver suficiente información estructurada para que el modelo pueda explicar lo ocurrido. Una herramienta de escritura puede incluir el objeto modificado, su estado anterior y el nuevo estado. Eso ayuda al host a presentar una confirmación significativa.

Las pruebas deben abarcar más que las llamadas exitosas. Los desarrolladores deberían probar tokens vencidos, permisos revocados, dependencias no disponibles, entradas malformadas e intentos de acceder a los registros de otro usuario. Los dos hosts pueden mostrar esos fallos de forma diferente.

Esto explica por qué añadir un servidor personalizado puede parecer lento pese a tratarse de un protocolo abierto. MCP elimina una categoría de duplicación en las integraciones. No elimina el despliegue, la identidad, la revisión de seguridad, la configuración del producto ni la garantía de calidad.

La verdadera disyuntiva es portabilidad frente a confianza

La misma apertura que permite a un servidor llegar a varios asistentes también le otorga una posición privilegiada entre los usuarios, los modelos y los sistemas sensibles.

Un servidor MCP personalizado puede ver las entradas enviadas a través de sus herramientas. Puede devolver contenido que el modelo trate como contexto. Si expone acciones, también puede modificar datos externos bajo la identidad del usuario.

Esa combinación crea varios límites de confianza. Los usuarios deben confiar en el proveedor de chat, el operador del servidor MCP, el servicio conectado y la implementación de autorización. Las organizaciones también deben confiar en las descripciones que guían el comportamiento del modelo.

La inyección de prompts es una preocupación importante. Una instrucción maliciosa puede incrustarse en datos recuperados por una herramienta, como un documento, un ticket de soporte o una página web. El modelo podría interpretar ese contenido como una indicación en lugar de material no confiable.

El riesgo aumenta cuando hay varias herramientas disponibles. El contenido recuperado podría intentar persuadir al modelo para que llame a otra herramienta con argumentos sensibles. Por tanto, una operación de lectura puede convertirse en el primer paso de una secuencia de escritura no deseada.

Tanto Anthropic como OpenAI advierten a los usuarios que conecten únicamente servidores de confianza. Ese consejo es necesario, pero la confianza no es un control de seguridad completo. Incluso un servidor bienintencionado puede contener errores de autorización o acciones excesivamente amplias.

El servidor debe validar cada solicitud de forma independiente. Nunca debería asumir que una llamada es segura porque Claude o ChatGPT la generaron. Las confirmaciones del host pueden ayudar a los usuarios, pero no sustituyen las comprobaciones de acceso del lado del servidor.

La gestión de tokens exige especial cuidado. La especificación MCP prohíbe el reenvío de tokens, en el que un servidor reenvía a otro servicio un token destinado a un servicio distinto. Los tokens deberían tener una audiencia definida, y el servidor receptor debería verificar esa audiencia.

El principio de mínimo privilegio ofrece el punto de partida más claro. Un conector de investigación debería solicitar acceso de lectura antes de pedir acceso de escritura. Una herramienta de calendario no debería solicitar permisos de eliminación cuando solo necesita listar disponibilidad.

Las operaciones de escritura también se benefician de una semántica limitada. Una herramienta llamada delete_everything es obviamente peligrosa, pero las funciones administrativas amplias pueden ocultar una exposición similar tras nombres más amigables. Cada acción debería corresponder a una intención de usuario revisable.

Las operaciones de alto impacto deberían admitir idempotencia, lo que evita que una repetición accidental produzca varios cambios. Un modelo podría reintentar tras una respuesta poco clara. Sin salvaguardas, una tarea solicitada podría crear registros o mensajes duplicados.

Los registros de auditoría son igualmente importantes. Los operadores necesitan saber qué usuario autorizó una llamada, qué herramienta se ejecutó, qué objeto cambió y si el host informó de una confirmación. Los registros deberían evitar retener contenido innecesario de prompts o secretos.

Los operadores de servidores deberían separar los datos orientados al usuario de las instrucciones de control. Los resultados de las herramientas pueden etiquetar claramente el texto no confiable y devolver campos estructurados cuando sea posible. Los modelos siguen siendo vulnerables a la manipulación, pero un diseño cuidadoso de las salidas reduce la ambigüedad.

Las plataformas host también afrontan cuestiones sin resolver. Sus solicitudes de aprobación deben proporcionar suficiente información para que los usuarios comprendan una acción. Una solicitud genérica para “permitir acceso a herramientas” ofrece poca protección cuando la herramienta puede realizar varias operaciones.

El comportamiento de las herramientas puede cambiar después de la conexión. Anthropic señala explícitamente que los desarrolladores de servidores pueden modificar las herramientas sin previo aviso. Un usuario que aprobó un conector de búsqueda inocuo podría encontrarse más adelante con capacidades más amplias desde el mismo endpoint.

El versionado y la revisión pueden reducir ese riesgo. Las organizaciones pueden fijar despliegues, supervisar cambios de esquema y exigir otra revisión cuando una herramienta obtiene acceso de escritura. Los operadores de servidores públicos pueden publicar registros de cambios y mantener estables los ámbitos.

También existe una cuestión de privacidad en torno al movimiento de datos. Una empresa puede permitir que su asistente busque en registros internos mientras prohíbe que esos registros lleguen a otro procesador. La ubicación de alojamiento y la política de retención del servidor MCP pasan a formar parte de la decisión.

Por tanto, un despliegue seguro necesita más que una conexión válida. Los equipos deberían documentar las categorías de datos, las acciones permitidas, los ámbitos de autenticación, las reglas de retención, los contactos para incidentes y los procedimientos de revocación. También deberían probar cómo informa cada host del uso de herramientas.

La demostración de anthropic simon prueba que la conectividad multiplataforma es posible. No prueba que todos los servidores accesibles sean adecuados para producción. La compatibilidad es el comienzo de la evaluación, no el final.

Esta distinción importa para los trabajadores del conocimiento que quieren que su asistente preferido acceda a notas privadas o al historial de proyectos. Un conector puede reducir la copia entre herramientas. También puede ampliar la vía por la que circula el contexto sensible.

Los equipos que evalúen esa disyuntiva deberían empezar con información que puedan permitirse exponer bajo acceso controlado. Una colección consultable de documentación de ingeniería aprobada es más segura que una puerta de enlace sin restricciones a todos los sistemas internos.

Después pueden medir si el asistente encuentra fuentes correctas, respeta los permisos y explica claramente el uso de herramientas. La ampliación debería seguir a la evidencia, no a la mera disponibilidad de un endpoint MCP.

Qué indica el experimento Simon de Anthropic que conviene vigilar a continuación

La próxima prueba de MCP será determinar si los servidores multiplataforma se convierten en productos habituales en lugar de integraciones especializadas configuradas mediante ajustes avanzados.

La primera señal es la convergencia en torno a la autorización remota. Tanto Claude como ChatGPT necesitan conectar a los usuarios de forma segura sin trabajo de registro personalizado para cada emparejamiento. La adopción más amplia se reforzará si un despliegue de OAuth compatible con el estándar funciona de forma fiable en ambos.

Si la autorización sigue llena de excepciones específicas de cada cliente, la promesa de portabilidad se debilita. Los desarrolladores seguirán reutilizando partes del servidor, pero mantendrán instrucciones de configuración, metadatos y rutas de solución de problemas por separado.

La evidencia más sólida vendrá de servicios ordinarios que publiquen un endpoint remoto con instrucciones verificadas para varios asistentes. Esos servicios no deberían exigir a los usuarios pegar claves de API de larga duración en la configuración del chat. El consentimiento basado en navegador debería conceder ámbitos limitados y revocables.

La segunda señal es cómo OpenAI amplía el acceso completo a MCP. La documentación actual distingue la compatibilidad total para cuentas gestionadas de lugares de trabajo de las capacidades Pro más limitadas. Una vía personal más amplia ejercería presión directa sobre la experiencia de conectores personalizados de Claude.

Un énfasis continuado en el despliegue administrado apuntaría a una estrategia diferente. Las apps de ChatGPT funcionarían principalmente como software de lugar de trabajo gobernado, mientras que Claude podría conservar una vía más directa para la experimentación individual.

Ninguna de las dos vías es automáticamente mejor. Las empresas suelen necesitar aprobación, auditabilidad y controles de roles. Los desarrolladores independientes valoran una ruta corta desde un servidor desplegado hasta una conversación funcional.

La tercera señal es cómo ambas plataformas gestionan las acciones de escritura. La búsqueda y la recuperación ofrecen demostraciones útiles, pero las acciones determinan si MCP se convierte en una verdadera capa de aplicaciones. También crean los problemas de seguridad e interfaz más difíciles.

Conviene vigilar resúmenes de permisos más claros, vistas previas de acciones, políticas de confirmación y registros de auditoría. Un host que explique bien los efectos externos puede hacer que las herramientas de escritura sean más utilizables sin fingir que no implican riesgos.

Los desarrolladores también deberían observar si los hosts ofrecen mejores diagnósticos. Los fallos de conexión suelen condensar varias causas posibles en un único error. El problema podría involucrar la negociación de transporte, metadatos de autorización, configuración de redirección, audiencia del token o validación del esquema de herramientas.

Mejores diagnósticos acortarían el camino de un servidor local funcional a una integración remota fiable. También reducirían la presión sobre los operadores de servidores para aplicar ingeniería inversa a las distintas expectativas de los hosts.

Los sistemas de registro y descubrimiento representan otra capa importante. Un protocolo abierto no indica a los usuarios qué servidores son fiables. Los directorios seleccionados pueden ayudar, pero también conceden a los propietarios de las plataformas otro punto de control.

Un servidor listado por un host podría seguir siendo una conexión personalizada manual en otro. Entonces, los desarrolladores afrontan un problema de distribución incluso cuando su implementación es portable. Los plazos de revisión y las reglas de listado pueden convertirse en elementos diferenciadores competitivos.

Por tanto, los usuarios deberían distinguir entre compatibilidad del servidor y disponibilidad del servidor. Un servicio puede funcionar técnicamente con Claude y ChatGPT y, aun así, seguir siendo difícil de encontrar o estar restringido por la política del espacio de trabajo.

La misma distinción se aplica a la compatibilidad de interfaces. MCP Apps puede devolver interfaces interactivas en hosts compatibles, mientras que los servidores de herramientas básicos intercambian principalmente datos estructurados y texto. Los distintos niveles de compatibilidad pueden hacer que una integración parezca más completa pese a utilizar el mismo protocolo subyacente.

Para los creadores, la estrategia inmediata es conservadora. Alojen un servidor remoto compatible con el estándar, comiencen con una herramienta de lectura limitada y prueben prompts idénticos en ambos productos. Registren cada diferencia en autenticación, descubrimiento, invocación y gestión de errores.

A continuación, introduzcan una acción de escritura limitada tras una autorización explícita. Confirmen que los reintentos no dupliquen cambios y que la revocación funcione. Revisen exactamente qué muestra cada plataforma antes de que se ejecute la acción.

Para las organizaciones, la decisión debería comenzar con el flujo de trabajo, no con el entusiasmo por MCP. Identifiquen una tarea repetida en la que el acceso basado en chat reduzca un cambio real de contexto o el esfuerzo de búsqueda. Después definan el menor alcance de datos y acciones necesario para completarla.

Un buen candidato podría buscar documentos técnicos aprobados y devolver enlaces a las fuentes. Otro podría redactar una actualización de proyecto sin publicarla. Ambos aportan valor mientras mantienen los cambios finales bajo control humano.

La frase de búsqueda "anthropic simon" probablemente atraerá a lectores que buscan el experimento específico de Simon Willison. Su valor duradero es más amplio que la secuencia de configuración. La prueba revela dónde termina la estandarización del protocolo y dónde comienza la política de la plataforma.

MCP ha cruzado una frontera importante al integrarse en las interfaces estándar de Claude y ChatGPT. La siguiente pregunta es si conectar un servidor de confianza se vuelve algo sencillo, predecible y visible para los usuarios comunes.

Los desarrolladores pueden ayudar a responder esa pregunta ahora. Elijan un flujo de trabajo de bajo riesgo, construyan un endpoint remoto con permisos limitados y comparen ambos hosts con los mismos prompts de prueba. Las diferencias mostrarán si MCP ofrece una portabilidad práctica o solo una base técnica compartida.