Hicimos cada post visible para los agentes de IA — así funcionan WebMCP y schema.org juntos
Dos canales complementarios que cubren todo el espectro: schema.org para el crawler que indexa, WebMCP para el agente que ejecuta.
Si publicas un post hoy y un agente de IA visita la página, hay dos lecturas que tiene que poder hacer. Una es el HTML estático: el agente quiere indexar tu contenido, citar partes, sintetizar respuestas para sus usuarios. La otra es interactiva: el agente quiere buscar entre tus posts, filtrar por tag, leer un post específico sin scrapear la página.
Ninguna se cubre con la otra. Los dos canales son complementarios, y al diseñar Agentikas decidimos que todo blog en la plataforma habla los dos desde el primer post, sin que el autor configure nada.
Canal 1: schema.org JSON-LD en cada página
Schema.org es el lenguaje compartido que entienden los crawlers. Google lo lee. Bing lo lee. Los crawlers de IA — GPTBot, ClaudeBot, PerplexityBot — lo leen mejor que el HTML semántico, porque les ahorra interpretación.
El componente que renderiza un post incluye, antes del cierre del <article>, un <script type="application/ld+json"> con el grafo completo:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "WebMCP: el protocolo que está cambiando las reglas",
"datePublished": "2026-03-21T00:00:00Z",
"dateModified": "2026-04-30T08:50:52Z",
"author": { "@type": "Person", "name": "Salvador Morales" },
"publisher": {
"@type": "Organization",
"name": "Agentikas Labs",
"logo": { "@type": "ImageObject", "url": "https://agentikas.ai/logo.png" }
},
"image": "https://images.unsplash.com/photo-1518432031352-d6fc5c10da5a",
"inLanguage": "es-ES",
"keywords": ["WebMCP", "Tecnología", "Open Source"]
}
</script>
Lo importante de este JSON-LD no es que esté — es que está en el HTML inicial, no inyectado por JavaScript. Si lo metes después de la hidratación, los crawlers de IA no lo ven. Esto va de la mano con la decisión de SSR en el edge — el JSON-LD sale como parte del primer byte.
Y va más allá del post individual. La home del blog inyecta un grafo Blog que enlaza a los BlogPosting recientes, las páginas de tag inyectan CollectionPage, el autor inyecta Person. Cuando un agente sintetiza una respuesta sobre Agentikas, no tiene que adivinar la estructura — la lee.
Canal 2: WebMCP, la API del navegador para agentes
Schema.org cubre al crawler. No cubre al agente que está ejecutando ahora mismo, dentro del navegador del usuario, decidiendo qué hacer en respuesta a una pregunta. Para eso existe WebMCP — un estándar abierto impulsado por Google y Microsoft, propuesto al W3C.
WebMCP no es un manifiesto remoto ni un endpoint en /.well-known/: es una API del propio navegador. Una página web registra sus herramientas en runtime contra navigator.modelContext, y los agentes activos en esa pestaña — Claude for Chrome, extensiones MCP en Gemini, el modo agente de ChatGPT — las descubren al cargar la página y pueden invocarlas directamente.
La estructura mínima que registra una página es esta:
navigator.modelContext.provideContext({
tools: [
{
name: "search_posts",
description: "Búsqueda full-text sobre los posts de este blog.",
inputSchema: {
type: "object",
properties: {
query: { type: "string" },
limit: { type: "integer", default: 10, maximum: 50 }
},
required: ["query"]
},
execute: async ({ query, limit = 10 }) => {
const res = await fetch(
"/api/blog/search?q=" + encodeURIComponent(query) + "&limit=" + limit
);
return res.json();
}
}
// ...más tools
]
});
Tres detalles que cambian la mentalidad respecto a APIs tradicionales:
- Cero claves de API. El
execute()corre en el JavaScript de la página, en el navegador del usuario. Hereda sus cookies, su sesión, sus permisos. Mismas credenciales que cuando navega manualmente. - Mismo origen. Las llamadas
fetch()dentro deexecuteson same-origin con tu sitio. No hay CORS, no hay tokens cruzados, no hay un servidor MCP remoto que mantener. - Auto-descripción por tool. Cada tool lleva su nombre, descripción en lenguaje natural y JSON Schema de argumentos. Un agente que nunca ha visto tu sitio entiende qué ofreces sólo cargando la página, igual que un humano entiende un formulario al verlo.
Las tools que registramos en cada blog
En cualquier blog de Agentikas Labs, el SDK registra cuatro tools en cuanto la página termina de hidratar:
navigator.modelContext.provideContext({
tools: [
{
name: "search_posts",
description: "Búsqueda full-text sobre los posts publicados.",
inputSchema: {
type: "object",
properties: {
query: { type: "string", description: "Texto a buscar." },
limit: { type: "integer", default: 10, maximum: 50 }
},
required: ["query"]
},
execute: async ({ query, limit = 10 }) => {
const res = await fetch(
"/api/blog/search?q=" + encodeURIComponent(query) + "&limit=" + limit
);
return res.json();
}
},
{
name: "get_post",
description: "Obtiene un post por slug, devuelve markdown y metadatos.",
inputSchema: {
type: "object",
properties: { slug: { type: "string" } },
required: ["slug"]
},
execute: async ({ slug }) => {
const res = await fetch("/api/blog/posts/" + slug);
if (!res.ok) throw new Error("Post no encontrado");
return res.json();
}
},
{
name: "list_recent_posts",
description: "Lista los últimos N posts publicados.",
inputSchema: {
type: "object",
properties: {
limit: { type: "integer", default: 10 },
locale: { type: "string", enum: ["es", "en"] }
}
},
execute: async ({ limit = 10, locale = "es" }) => {
const res = await fetch(
"/api/blog/recent?limit=" + limit + "&locale=" + locale
);
return res.json();
}
},
{
name: "list_tags",
description: "Tags utilizados en el blog con número de posts por tag.",
execute: async () => (await fetch("/api/blog/tags")).json()
}
]
});
Cuando un agente compatible invoca search_posts({ query: "WebMCP" }), no scrapea HTML: ejecuta el execute de esa tool, que dentro hace un fetch contra una API JSON tipada. Si cambias el diseño del blog mañana, las tools siguen funcionando exactamente igual. Es la diferencia clave con scraping.
Cómo probar WebMCP tú mismo en 5 minutos
WebMCP es nuevo: no todos los navegadores lo soportan nativamente todavía. Hay dos caminos para inspeccionar las tools que registra cualquier sitio compatible y jugar con ellas. El más rápido es la extensión oficial de Chrome; el más "purista" es Chrome Canary con la feature flag nativa.
Opción A — La extensión "WebMCP - Model Context Tool Inspector" (recomendada)
- Instala la extensión. Está publicada en la Chrome Web Store: WebMCP - Model Context Tool Inspector. Funciona en Chrome y derivados (Brave, Edge, Arc) sin cambiar de navegador.
- Visita un post de Agentikas Labs, por ejemplo el artículo sobre el protocolo WebMCP. Espera a que la página termine de cargar.
- Abre el panel de la extensión haciendo clic en su icono en la barra de herramientas. Verás la lista de tools que esta página ha registrado en
navigator.modelContext:search_posts,get_post,list_recent_posts,list_tags. Cada una con su descripción y su input schema. - Invoca una tool manualmente. La extensión genera un formulario a partir del JSON Schema. Prueba
search_postsconquery: "WebMCP"ylimit: 5. Verás la respuesta JSON exactamente como la recibiría un agente. - Inspecciona el contrato. La extensión muestra el JSON Schema del input y la forma de la respuesta. Esto es lo que un agente IA usa para entender qué hace tu sitio sin documentación humana.
El valor de la extensión es que te pone literalmente en la posición del agente: ves exactamente lo mismo que ve Claude for Chrome o cualquier cliente MCP cuando aterriza en tu sitio.
Opción B — Chrome Canary con la feature flag nativa
Si quieres ver el soporte nativo del navegador (sin extensión), tal y como se está estandarizando en el W3C:
- Descarga Chrome Canary desde google.com/chrome/canary. Es la rama más adelantada de Chrome, donde se prueban features experimentales antes de llegar a Stable.
- Habilita la flag. Abre
chrome://flagsen Canary y busca "Model Context" o "WebMCP". Activa la entrada (típicamente etiquetada Web Model Context API) y reinicia Canary cuando lo pida. - Verifica que la API existe. Abre cualquier post de Agentikas Labs y, en la consola de DevTools (
Cmd+Option+Jen macOS), ejecuta:typeof navigator.modelContext // "object" → soporte nativo activo // "undefined" → la flag no está habilitada o tu Canary es muy antiguo - Inspecciona las tools registradas:
navigator.modelContext.tools.map(t => t.name) // ["search_posts", "get_post", "list_recent_posts", "list_tags"] - Invoca una tool desde la consola:
La respuesta será el mismo JSON que vería un agente IA — un array de posts con título, slug, fecha y resumen.await navigator.modelContext.tools .find(t => t.name === "search_posts") .execute({ query: "WebMCP", limit: 5 });
El soporte nativo cambia rápido: la API exacta puede tener pequeñas variaciones entre versiones de Canary. La extensión del Chrome Web Store usa internamente un polyfill equivalente, así que para inspección práctica los resultados son idénticos.
Qué mirar una vez que ves las tools
Después de invocar search_posts o list_recent_posts en cualquiera de las dos opciones, fíjate en la forma de la respuesta. Es lo que define qué es posible para un agente con tu sitio:
- Si tu blog devuelve un objeto rico (slug, título, autor, tags, fecha, resumen), un agente puede sintetizar una respuesta completa sin volver a scrapear la página.
- Si devuelves sólo URLs, lo único que el agente puede hacer es enlazar — pierdes el control de cómo se cita tu contenido.
- Si las descripciones de cada tool son vagas o ambiguas, el agente las usará menos. Las descriptions de las tools son el copy que vende tu sitio a los agentes.
Por qué los dos canales, no uno
La pregunta razonable es: si WebMCP permite ejecución programática rica, ¿por qué seguir gastando bytes en schema.org? Tres razones:
- WebMCP requiere ejecución. Sólo funciona cuando un agente está vivo en el navegador del usuario — Claude for Chrome activado, extensión MCP corriendo, modo agente de ChatGPT abierto. Schema.org funciona en el crawler offline, semanas antes, indexando para futuras consultas.
- Distinta superficie semántica. Schema.org describe qué es el contenido (autor, fecha, idioma, palabras clave). WebMCP describe qué se puede hacer con él (buscar, listar, leer un post concreto). Los dos importan.
- Adopción incremental. Schema.org tiene 15 años de adopción. WebMCP es de 2026. Los agentes que ya están en producción aprovechan los dos canales según su capacidad — los más nuevos invocan tools, los más antiguos leen JSON-LD. No vamos a esperar a que todos hablen WebMCP para que nuestro contenido sea legible hoy.
La consecuencia práctica: no es una decisión, son dos features paralelas, y las dos se sirven gratis si la plataforma está bien diseñada.
El robots.txt que invita en vez de bloquear
El detalle final: los dos canales son inútiles si bloqueas a los crawlers. La mayoría de blogs hoy bloquean GPTBot, ClaudeBot y Google-Extended por paranoia. En Agentikas el default es opuesto:
User-agent: GPTBot
Allow: /
User-agent: ClaudeBot
Allow: /
User-agent: Google-Extended
Allow: /
User-agent: PerplexityBot
Allow: /
Bloquear a los bots de IA hoy es la versión 2026 de "no quiero estar en Google". Puedes hacerlo. Tus visitantes futuros, también pueden no encontrarte.
El SDK de WebMCP que registra estas tools es open source: github.com/agentikas/agentikas-webmcp-sdk. Funciona con cualquier sitio que tenga schema.org bien puesto — no sólo con los que corren en Agentikas. Para inspeccionar las tools de cualquier web compatible, instala la extensión WebMCP - Model Context Tool Inspector.
Comentarios
Cargando comentarios…
Inicia sesión en tu dashboard para participar.