MCP, llms.txt y WebMCP: tres formas de que un agente entienda tu web (y cuál necesitas)
No son tres fases de lo mismo ni compiten entre sí: responden a tres preguntas distintas según dónde esté el agente. Montamos las tres en nuestra web y medimos lo que cuesta cada una, con los bytes reales que viajan por el cable.
Resumen ejecutivo
- No son tres fases de lo mismo. El llms.txt describe, MCP ejecuta y WebMCP actúa dentro de la pestaña. La pregunta que las separa no es cuál es más moderna, sino dónde está el agente cuando necesita algo de ti.
- Montamos un servidor MCP público en nuestra web y lo medimos contra producción. Responder «qué servicios hay y cuánto cuestan» cuesta 137.499 bytes por HTML —de los que solo 4.960 caracteres son texto— frente a 7.650 bytes por herramienta MCP, con 7.360 caracteres aprovechables. Dieciocho veces menos tráfico y casi un 50 % más de contenido útil.
- El coste que nadie cuenta: el catálogo de herramientas ocupa 6.861 bytes en la ventana de contexto del agente aunque no llame a ninguna. Cinco herramientas es barato; cuarenta no.
- WebMCP no está en ningún navegador estable. Origin trial en Chrome 149 desde el 9 de junio de 2026 y en Edge 150; Chrome Status lo clasifica como «Proposed» e «Incubation»; Firefox y Safari, «No signal». Y la API es
document.modelContext, nonavigator.modelContextcomo repiten medio internet y bastantes generadores de contenido. - Si solo puedes hacer una cosa esta semana, no es ninguna de las tres: es que tu contenido sea legible sin ejecutar JavaScript. Las tres capas dan por supuesto lo que a la mayoría de las webs le falta.
Desde que el Model Context Protocol se hizo popular, en cada conversación sobre visibilidad en IA aparece la misma pregunta mal formulada: «¿tengo que poner MCP, llms.txt o eso nuevo del navegador?». Está mal formulada porque asume que son alternativas, cuando en realidad ni siquiera operan en el mismo punto del recorrido.
He implementado las tres en esta web —dos en producción, la tercera a modo de prueba— y he medido lo que cuestan. Lo que sigue es el criterio para decidir, con los números delante.
Las tres, en una frase cada una
| llms.txt | MCP | WebMCP | |
|---|---|---|---|
| Qué es | Un fichero de texto en la raíz | Un servidor remoto que expone herramientas | Una API del navegador dentro de tu página |
| Qué responde | Qué hay en esta web | Qué puede hacer este servicio por ti | Qué puede hacer el usuario en esta pantalla |
| Dónde está el agente | Leyendo tu contenido | En otra aplicación, llamando a tu backend | Dentro de la pestaña, con la sesión iniciada |
| Quién lo consume | Un humano que lo pega; algún crawler | Clientes MCP: Claude, ChatGPT, Cursor, IDEs | El agente integrado en el navegador |
| Estado | Propuesta sin adopción confirmada | Estándar de facto, revisión 2026-07-28 | En incubación, origin trial |
| Esfuerzo | Media hora | Días | Horas por formulario |
| Lo hace descubrible | No | No | No |
La última fila es la que más discusiones ahorra. Ninguna de las tres te hace más visible por sí misma. No hay crawler que premie un llms.txt, no hay índice que recoja tu servidor MCP y no hay buscador que ordene resultados por si declaras herramientas WebMCP. Las tres mejoran lo que ocurre después de que alguien te haya encontrado. Quien te las venda como canal de adquisición te está vendiendo otra cosa.
El único criterio que decide: dónde está el agente
Olvida las siglas un momento y responde a esta pregunta sobre tu negocio: cuando un agente de IA necesita algo de ti, ¿dónde está físicamente?
Hay tres respuestas posibles y cada una tiene su capa.
Está leyendo tu contenido, desde un índice o desde una cita. El agente no interactúa: extrae. Le importa que el texto esté en el HTML inicial, que las afirmaciones sean autocontenidas y que la marca esté declarada como entidad. Aquí la herramienta es el contenido mismo, el schema JSON-LD y, marginalmente, el llms.txt. Es el caso del 95 % de las webs, y es donde se juega la citación en motores generativos.
Está en otra aplicación y quiere que hagas algo por él. El usuario está hablando con Claude o con ChatGPT, no ha abierto tu web y probablemente no la abra. Si lo que ofreces es un cálculo, una búsqueda sobre datos que solo tú tienes o una consulta a tu catálogo, un servidor MCP convierte eso en una herramienta invocable. Si lo que ofreces es solo información, no hace falta: para eso está el HTML.
Está dentro de tu pestaña, con la sesión del usuario abierta. Este es el caso que ni el HTML ni MCP resuelven bien. El agente ve la página, el usuario ha iniciado sesión, hay estado en el cliente —un carrito, un filtro aplicado, un formulario a medio rellenar— y la alternativa actual es que el agente simule clics sobre el DOM. Para eso es WebMCP, y para nada más.
Esa tercera categoría es más pequeña de lo que el ruido sugiere. Si tu web es un sitio de servicios con un formulario de contacto, vives casi entera en la primera.
llms.txt: lo barato que puede que no sirva
Le dedicamos un artículo entero y la conclusión no ha cambiado: Ahrefs analizó en mayo de 2026 los 137.210 dominios de su panel y encontró que el 97 % de los ficheros llms.txt válidos no recibió ni una sola petición en un mes. Ninguna plataforma ha confirmado públicamente que lo use.
Lo mantenemos igualmente, por dos motivos que sí se sostienen y conviene separar del marketing:
- Como contexto que se pega a mano. Cuando alguien quiere que un modelo entienda nuestra web entera, pegar 30.625 bytes de resumen estructurado funciona mucho mejor que pedirle que navegue. Ese uso es real y es el que tiene hoy.
- Como fuente canónica interna. Nuestro
llms.txtse genera del mismo sitio del que sale la web, así que no es contenido paralelo que mantener. Volveremos sobre esto, porque es la diferencia entre que esto sume o reste.
En cifras de esta web: /llms.txt pesa 30.625 bytes y /llms-full.txt —la versión con el contenido completo— 133.609. Ese segundo fichero es del tamaño de una sola de nuestras páginas HTML, y contiene todo el sitio. Esa proporción es el argumento entero a favor del formato.
Media hora de trabajo, cinco puntos en la mayoría de escáneres del mercado —incluido el nuestro, que también se los da— y ninguna evidencia de impacto en citación. Hazlo, pero no lo cuentes como una victoria.
MCP: lo montamos y estas son las cifras
El Model Context Protocol es lo más maduro de los tres: revisión actual de la especificación 2026-07-28, implementaciones en todos los clientes relevantes y un registro oficial. Nuestro servidor está publicado allí desde el 10 de septiembre de 2026 con el identificador com.autoridaddigital.www/geo, y responde en https://www.autoridaddigital.com/api/mcp por Streamable HTTP, sin autenticación y sin estado.
Expone cinco herramientas —escanear una web, comparar varias, consultar el glosario, buscar en el blog y devolver servicios y precios—, dos flujos guiados y el llms.txt como recurso. Todo de solo lectura y todo leído de las mismas constantes que renderizan la web.
Lo que cuesta responder una pregunta
Aquí está la medición que importa, hecha contra producción con curl el 20 de septiembre de 2026. La pregunta es la misma en los tres casos: «¿qué servicios ofrece esta agencia y cuánto cuestan?».
Medido contra www.autoridaddigital.com el 20 de septiembre de 2026. Cuerpo de la respuesta, sin cabeceras.
Y lo que llega dentro de esos bytes:
| Vía | Bytes transferidos | Texto aprovechable | Señal |
|---|---|---|---|
HTML de /precios | 137.499 | 4.960 caracteres | 3,6 % |
llms.txt (todo el sitio) | 30.625 | ~30.000 caracteres | ~98 % |
Herramienta servicios_y_precios | 7.650 | 7.360 caracteres | 96 % |
La página de precios dedica el 96,4 % de su peso a marcado, scripts, estilos y datos de hidratación. No es un defecto de esta web en particular: es lo que hace cualquier aplicación moderna, y es el motivo por el que un agente que raspa HTML gasta mucho contexto para obtener poco.
El caso del glosario es aún más marcado. La página /glosario/geo-generative-engine-optimization pesa 116.551 bytes y deja 7.014 caracteres de texto plano, pero ese texto incluye el menú, las migas, los términos relacionados, la llamada a la acción y el pie. La herramienta consultar_glosario devuelve 990 bytes con los 881 caracteres de la definición corta y larga, y nada más. Ciento dieciocho veces menos tráfico para obtener exactamente el dato que se pidió.
El coste fijo que casi nadie menciona
Antes de que esto suene a que MCP es gratis: no lo es.
Un cliente MCP pide el catálogo de herramientas al conectarse y lo mantiene en la ventana de contexto del modelo durante toda la sesión. Nuestro tools/list devuelve 6.861 bytes de esquemas JSON para cinco herramientas, con descripciones de entre 252 y 511 caracteres cada una. Ese texto ocupa contexto siempre, se use o no se use ninguna herramienta.
Con cinco herramientas es una ganga: se amortiza en la primera llamada. Con cuarenta herramientas mal descritas, el servidor empeora al agente que lo instala —gasta contexto, aumenta la probabilidad de que elija la herramienta equivocada y ralentiza todo—. La propia documentación de WebMCP avisa de lo mismo para su caso: cada herramienta registrada consume tokens en el prompt del modelo, y recomienda no registrar decenas ni centenares.
Es la regla de diseño que se ignora sistemáticamente cuando alguien monta su primer servidor: pocas herramientas, bien descritas, que devuelvan poco. Un servidor MCP no es una API REST con otra sintaxis; es un fragmento de prompt permanente.
Lo que no vamos a contarte, y por qué
Aquí toca ser explícito, porque el hueco se nota.
No vamos a enseñarte cuántas veces al día se llama a nuestro servidor MCP. El servidor registra una línea JSON por llamada —qué método y qué herramienta, sin IP, sin cookies y sin las URLs analizadas—, pero esas líneas van a los logs de ejecución de Vercel, que tienen una retención de horas: la API devuelve los últimos cien eventos y poco más. Publicar «X llamadas» a partir de una ventana de siete minutos sería exactamente el tipo de cifra que criticamos en otros.
Lo honesto es decir lo que hay: el servidor está publicado, activo en el registro oficial y funciona; la medición de uso agregado exige un log drain o un contador persistente que todavía no hemos montado. Cuando lo esté y haya un mes de datos, se publica —con el número que salga, incluido si es decepcionante—.
Y una advertencia comercial que vale por todo lo demás: un servidor MCP no se descubre navegando. El usuario tiene que añadirlo a mano a su cliente. No es un canal de captación; es una herramienta para quien ya te conoce y una señal de entidad para quien evalúa si sabes de lo que hablas.
WebMCP: qué es de verdad, en septiembre de 2026
Aquí es donde conviene ir a la fuente primaria, porque el contenido publicado sobre WebMCP está mayoritariamente equivocado en los detalles que importan.
La API es document.modelContext, no navigator.modelContext. Buena parte de los artículos que aparecen primero al buscar —incluidos varios que anuncian compatibilidad con navegadores concretos— usan el nombre de un borrador anterior. La especificación que mantiene el W3C Web Machine Learning Community Group define hoy document.modelContext.registerTool(), document.modelContext.getTools(), document.modelContext.executeTool() y un evento toolchange. Copiar el nombre viejo no da error: simplemente no registra nada, y lo descubres tarde.
Una herramienta se declara así, con nombre, descripción en lenguaje natural, esquema de entrada y una función que reutiliza el código que ya tiene la página:
await document.modelContext.registerTool({
name: "filtrar_plantillas",
description: "Filtra las plantillas visibles por tema y color de fondo",
inputSchema: { /* JSON Schema de los parámetros */ },
async execute({ tema, fondo }) {
aplicarFiltros({ tema, fondo }); // el mismo código que usa el botón
return { content: [{ type: "text", text: resumenDeResultados() }] };
},
});
Hay además una vía declarativa para exponer un <form> existente como herramienta, sin escribir JavaScript nuevo. Y un control de permisos por cabecera: Permissions-Policy: tools=() desactiva el registro, y registerTool() rechaza con NotAllowedError.
El estado real de implementación
| Navegador / agente | Estado a 20 de septiembre de 2026 |
|---|---|
| Chrome | Origin trial desde Chrome 149, anunciado el 9 de junio de 2026. Flag local enable-webmcp-testing |
| Edge | Origin trial en Edge 150 |
| Brave | Soporte experimental en Leo |
| ChatGPT Desktop | Compatible |
| Firefox | «No signal» en Chrome Status; issue abierto en standards-positions |
| Safari | «No signal» en Chrome Status; issue abierto en WebKit standards-positions |
Y la clasificación oficial, que es la que desmonta los titulares: Chrome Status marca la función como «Proposed» y la madurez de la especificación como «Specification being incubated in a Community Group». Es decir: no está en la vía de estándar del W3C, ningún navegador lo ha enviado a estable, y dos de los cuatro motores no se han pronunciado.
Un origin trial es acceso anticipado con fecha de caducidad y límites de uso, pensado para recoger opiniones de desarrolladores. No es una función que puedas dar por disponible para tus usuarios.
Lo que sí conviene hacer hoy
Y aun así, hay trabajo que rinde ya, porque no depende de que la API se active.
Si diseñas tus formularios como si fueran herramientas —campos con nombres explícitos, valores enumerados en lugar de texto libre, estados de error legibles, una confirmación en texto de lo que ha ocurrido—, ese trabajo sirve en los tres escenarios: mejora la accesibilidad, mejora lo que un agente puede hacer hoy por actuación sobre el DOM, y es exactamente lo que WebMCP formalizará después. Lo desarrollamos en la guía agent-first para webs de servicios.
Lo que no conviene es reescribir la aplicación alrededor de una API en incubación que la mayoría de tus visitantes no puede ejecutar.
Cuál necesitas tú
| Tu situación | llms.txt | MCP | WebMCP |
|---|---|---|---|
| Web de servicios con formulario de contacto | Sí, media hora | No | No, pero diseña el formulario como herramienta |
| Blog, medio o web de contenido | Sí | No | No |
| Documentación técnica o base de conocimiento | Sí, aquí es donde más rinde | Sí, si hay búsqueda o API que consultar | No |
| SaaS con aplicación en cliente y sesión | Sí | Sí, para la parte de backend | Sí, es tu caso: es para lo que se diseñó |
| Ecommerce | Sí | Solo si tienes catálogo consultable | Sí, para filtros y carrito |
| Herramienta o calculadora propia | Sí | Sí, es el caso más claro | Según dónde viva la lógica |
La fila que más gente quiere saltarse es la primera. Si tienes una web de servicios, tu trabajo no está en ninguna de las tres columnas: está en que el contenido diga algo concreto, en que se lea sin JavaScript y en que tu precio sea recuperable. Las tres capas presuponen eso, y ninguna lo arregla.
El coste que se paga después: contenido paralelo
Hay un riesgo que comparten las tres y que no aparece en ningún tutorial: cada capa nueva es una copia más de la verdad que alguien tendrá que mantener sincronizada.
Un llms.txt escrito a mano se queda obsoleto el día que cambias de precios. Un servidor MCP con las descripciones de servicio copiadas y pegadas empieza a contradecir a la web en la primera actualización. Una herramienta WebMCP que duplica la lógica de un botón se rompe cuando el botón cambia. Y lo peor de la desincronización no es el error: es que la vía que solo leen las máquinas es la que nadie revisa, así que el error puede vivir meses.
La única forma de que esto no pase es estructural: una sola fuente, tres salidas. En esta web, los precios, los servicios y las preguntas frecuentes viven en un único módulo de constantes del que se alimentan a la vez la página, el llms.txt y la herramienta MCP. Cambiar un precio es cambiar un número en un sitio. Si tu implementación requiere acordarse de actualizar tres ficheros, no la montes: el día que se olvide alguien —y se va a olvidar— estarás dándole a un agente datos que tu web desmiente.
Ese principio, y no la elección de protocolo, es lo que separa una infraestructura para agentes que aguanta de una que se pudre en seis meses.
Qué haría yo en tu web esta semana
En este orden, y parando en cuanto se acabe el presupuesto:
- Comprueba que tu contenido existe sin JavaScript.
curla tu página principal y a una de servicio, y cuenta las palabras. Si salen menos de 300, nada de lo demás importa. Puedes hacerlo con el escáner gratuito en diez segundos. - Comprueba el acceso real de los bots, no la política declarada. Que
robots.txtlos permita no significa que tu WAF los deje entrar. Esto es lo primero que miramos en una auditoría y lo que más veces aparece roto. - Publica el precio, o el rango. Si un agente no lo encuentra en tu web, lo busca en un directorio que tú no controlas.
- Genera el llms.txt desde tu fuente de datos, no a mano. Media hora, valor incierto, coste de mantenimiento cero si se hace bien.
- Rediseña un formulario como herramienta. Campos nombrados, valores enumerados, confirmación en texto. Sirve hoy y servirá cuando WebMCP salga de incubación.
- Monta un servidor MCP solo si tienes una función que ofrecer. Pocas herramientas, descripciones cortas, respuestas pequeñas. Si lo único que ibas a exponer es tu catálogo de servicios en texto, eso ya está en tu web.
La pregunta con la que empieza este artículo tiene respuesta, y para la mayoría de los negocios es incómoda por lo aburrida: probablemente no necesitas ninguna de las tres todavía. Lo que necesitas es que lo que ya tienes se pueda leer. Las tres capas sirven para que un agente trabaje mejor con tu contenido; ninguna sirve para que haya contenido.
Decidir cuál de las tres necesitas es media hora. Implementarla bien es el trabajo.
Trabajamos la capa técnica de visibilidad en motores generativos de punta a punta: acceso real de los crawlers, extractibilidad por plantilla, señales de entidad y —cuando tiene sentido— la infraestructura para agentes. Con el criterio para no montar lo que no vas a mantener.
Ver cómo trabajamos GEOFOUNDER & SEO LEAD
Founder de Autoridad Digital. Especialista en SEO, Generative Engine Optimization, Topical Authority y Authority Stacking, PR Digital. Todos los artículos del blog están firmados por él.
¿Te resulta útil este contenido? Añadinos como fuente preferida en Google.
Activa las cookies de terceros (Google) para ver este botón.