Interoperabilidad agéntica para tu web: qué es la AI UX

He seguido de cerca el tema emergente de la «interoperabilidad agéntica» en todos mis proyectos de construcción recientes. En palabras llanas, es la capacidad de los agentes de IA para hacer cosas por ti en tu nombre, sobre todo dentro de apps SaaS mediante servidores MCP y, cada vez más, vía WebMCP, un protocolo emergente que llena el hueco entre el marcado simple de datos estructurados y que un agente pueda interactuar con una web de forma adecuada.

En este post te enseñaré lo que he cableado en mis propios proyectos y veremos ejemplos de dos industrias (alquiler de coches y viajes) donde el tema ya no se puede evitar mucho más tiempo.

No es un post de «AI SEO». Trata sobre qué pasa cuando tus agentes personales empiezan a completar tareas por ti sin que pinches ni un solo enlace.Ese es el futuro hacia el que vamos: ¿para qué buscar si tu agente puede hacerlo todo por ti?

---

Por qué esto no es AI SEO

La mayor parte del ruido sobre AI SEO ahora mismo es gente intentando manipular qué frases elige ChatGPT cuando resume la web. Es un problema real que resolver, claro. Pero no es el cuadro completo si llevas una web que hace algo más que publicar.

La pregunta a la que sigo volviendo es qué pasa cuando el cliente no te visita en absoluto. Su agente personal se va y reserva el coche de alquiler, reserva el vuelo, le apunta a la prueba. Un agente, buscando en tu inventario por API (u otros medios) una buena oferta mientras el usuario del agente está en la cocina preparándose la comida.

Eso ya está pasando en pequeños bolsillos. Lastminute.com es el ejemplo obvio: lanzaron un servidor MCP para su inventario de vuelos en enero de 2026 y su CEO ha sido bastante franco sobre que es un movimiento de supervivencia. Stripe, Shopify, Cloudflare, Atlassian, Linear, Asana: todos SaaS, todos han lanzado MCPs, todos apuestan por el mismo cambio. La mayoría de apps SaaS serias ya tiene un MCP y algunas, como Salesforce, van headless (¡un SaaS sin UI!).

Salesforce anuncia Salesforce Headless 360

Para mí, la ficha cayó a mediados de 2025. La pregunta correcta para un dueño de web no es «cómo consigo que me cite ChatGPT». Es: cuando un agente se presente en mi puerta, ¿qué encuentra, y puede hacer algo útil con mi producto?

Para la mayoría de webs que he tocado últimamente, la respuesta es: muy poco.

modelcontextprotocol.io: la especificación, los SDK, los servidores de referencia

Tras pensarlo un rato, he llegado a la noción de AI UX: la experiencia de usuario para agentes automatizados.

La interoperabilidad agéntica es más una pila que una sola cosa, lo cual forma parte de por qué tantos equipos se bloquean con ella. Cada capa que añades te hace un poco más legible para los agentes. Lo pienso como ocho peldaños: puedes hacer uno, puedes hacerlos todos, según lo en serio que quieras optar:

Interoperabilidad agéntica: esfuerzo frente a capacidad

Naturalmente, la clave de todo esto es entender. No basta con implementar lo siguiente por implementar: hay que pensar en el caso de uso agéntico. Y sí, todo esto es increíblemente orientado al futuro, pero con la IA los años se han vuelto meses y los meses, semanas. Yo no dormiría sobre esta línea de pensamiento, si fuera tú.

¿Quieres implementar algo de soporte para agentes en tu web, por delante de la curva? Ahora es el momento.

A fecha de abril de 2026, hay ocho opciones trazadas por esfuerzo frente a capacidad. Empieza abajo a la izquierda y sube.

1. Gobernanza: robots.txt y directivas de IA, decide qué agentes dejas entrar en absoluto
2. Optimización del DOM: HTML semántico y etiquetas ARIA para agentes que conducen el navegador
3. Negociación de contenido: servir markdown cuando un agente lo pida
4. Feeds: JSON, RSS, XML, Atom
5. API REST + un manifiesto OpenAPI en una URL conocida
6. Marcado Schema.org, incluidas las partes ejecutables como Action y Dataset
7. WebMCP: registro de herramientas en el navegador que el agente puede invocar sin cambio de contexto
8. Un servidor MCP independiente: la respuesta estilo SaaS, a un npm install de distancia

No tienes que hacerlos en este orden. Cuanto más subes, más determinista y fiable te vuelves para el agente.

1. Gobernanza: robots.txt y directivas de IA

La primera decisión de interoperabilidad que toma un dueño de web no trata de exponer datos, sino de decidir qué agentes dejas entrar en absoluto. Es el peldaño que puedes sentir la tentación de saltarte porque no parece «trabajo de IA», pero marca el tono de todo lo que sigue.

En concreto: entradas de robots.txt para los user-agents de agentes que de verdad te importan (GPTBot, ClaudeBot, PerplexityBot, Google-Extended, OAI-SearchBot y demás). Decide qué puede rastrear cada uno, qué está vedado y hacia dónde prefieres dirigirlos. Cloudflare añadió un clic en su interfaz para bloquear rastreadores de IA en 2025 y mucha gente lo usa sin saberlo.

En resumen, para los agentes que quieres soportar, el truco es desviarlos de las páginas de marketing y hacia tu API o tu llms.txt. Una línea como Allow: /api/ junto a un Disallow: /checkout/ comunica mucho, sobre todo emparejada con rate-limiting en el edge para que un único agente no te vacíe el presupuesto de CPU un sábado por la mañana (presto mucha más atención a la caché a causa de los bots de entrenamiento de LLM).

Si eres una marca transaccional y ya has bloqueado en bloque a los rastreadores de IA, merece revisitarlo. Bloquear todo tiene la misma energía que un cartel de «no se admite publicidad» en la puerta de una tienda: funciona hasta que los clientes dejan de venir.

2. Optimización del DOM para agentes que conducen el navegador

Este peldaño se sienta entre la gobernanza y los datos estructurados, y probablemente no recibe la atención que necesita como asunto de «agente». Pero importa más de lo que crees.

Una parte real del tráfico de agentes en 2026 es de conducción del navegador. OpenAI Operator, Computer Use de Anthropic, los distintos agentes de extensión de Chrome: todos funcionan mirando la página renderizada (a menudo vía el árbol de accesibilidad, a veces vía una captura) y decidiendo qué pulsar. Cualquier cosa que harías por accesibilidad también ayuda a estos agentes. Etiquetas ARIA en los botones. HTML semántico para encabezados y controles de formulario. Atributos data-testid o id estables que no cambien entre despliegues. aria-label="Añadir a la cesta" en lugar de .

La mayoría de equipos de desarrollo modernos tienen una auditoría de accesibilidad en algún punto de su flujo. El truco es empezar a tratar la fiabilidad del agente como uno de los resultados que produce esa auditoría. Un botón confuso para un lector de pantalla es un botón confuso para un agente.

Por ahora, esta es una capa de respaldo: si tienes los peldaños superiores funcionando (API REST, servidor MCP, WebMCP), el agente nunca tiene que conducir la UI para empezar. Pero hasta que esos sean universales, un agente que aterrice en tu web puede seguir clicando visualmente por el flujo de reserva. Así que haz que ese flujo sea accesible.

3. Negociación de contenido

Mis facturas de hosting se han disparado: los LLM consumen ancho de banda como locos. La negociación de contenido es de las cosas que espero que se extiendan, porque servir markdown o json cacheado como tipo de contenido alternativo es una buena idea. Me resulta un poco raro que más webs no lo hayan hecho.

Cuando un agente moderno pide tu página, hay muchas probabilidades de que ya esté enviando Accept: text/markdown en las cabeceras de la petición. Cursor lo hace. Claude Code también: Anthropic lo confirmó de forma nativa a finales de 2025. La lista crece cada semana. El movimiento correcto en el servidor es detectar esa cabecera en el edge y devolver una versión markdown limpia de la página, en lugar de (respira hondo) 600 KB de shell de React, píxeles de publicidad, banners de cookies y trozos de analítica. Toda esa basura es irrelevante para un LLM y, si no, servir HTML a un bot de entrenamiento de LLM es como servir caviar a un niño. ¡No tiene ningún sentido!

En Yubhub, lo cableé a nivel de ruta. Tengo 2 rutas que sirven el mismo contenido en distintos formatos. Pide *.md directo y obtienes markdown. Pide /jobs/{id} con Accept: text/markdown y también obtienes markdown.

Misma URL, dos respuestas. El servidor inspecciona la cabecera Accept y enruta en consecuencia.

const r = await fetch('https://yubhub.co/jobs/' + id + '.md', {
  headers: { Accept: 'text/markdown' }
});
return { markdown: await r.text() };

Vercel y Cloudflare han lanzado versiones a nivel de red que cualquiera puede activar. Read the Docs ha hecho lo mismo para el hospedaje de documentación. El «Markdown for Agents» de Cloudflare se lanzó en febrero de 2026 y no es un estándar formal, pero dado la porción de la web que está tras el edge de Cloudflare, está convirtiéndose de facto en uno, le guste o no al IETF. Y, por otro lado, tiene todo el sentido que Cloudflare haga esto como medida de ahorro de ancho de banda. ¡No me imagino lo que esta época de tráfico excesivo de entrenamiento de LLM les está haciendo a sus servidores!

Si no haces nada más de esta lista, haz este.

Los feeds son viejos y pasados de moda. La razón por la que vuelven a importar ahora, en mi opinión, es que son una forma determinista de que un agente agarre una porción de tu inventario sin rastrear 10.000 páginas paginadas de JavaScript.

Construí feeds facetados en yubhub exactamente por eso. Cada categoría, cada cargo, cada empresa, cada habilidad tiene su propio feed en feeds.yubhub.co/facet/{type}/{slug}.{json|xml}. Así, si un agente (o un usuario humano de RSS, que aún existen) quiere «todos los empleos activos de ingeniería de datos en Londres con el término Snowflake», tira de una URL de feed y obtiene JSON o XML. Sin render de JavaScript. Sin baile de paginación. Sin rehidratación en el cliente que esperar.

{
  "uri": "https://feeds.yubhub.co/",
  "name": "XML feed index",
  "description": "Per-feed XML endpoints for third-party job boards"
}

llms.txt pertenece también a esta capa. Deja un archivo en la raíz de tu sitio listando tus URLs importantes de markdown, endpoints JSON y feeds. Merece ser honesto sobre el estado: llms.txt no es un estándar formal, y ni OpenAI ni Anthropic han confirmado oficialmente que GPTBot o Claude-Web lo procesen durante los rastreos abiertos de la web.

Lo que pasa es que los agentes de código (Cursor, Claude Code) y un ecosistema de tooling creciente lo usan durante la recuperación directa solicitada por el usuario. Es, como mucho, una señal suave por ahora, pero, otra vez, la escala es la clave. Si el edge de Cloudflare empieza a sacar llms.txt en su flujo Markdown for Agents (lo que parece probable), se convierte casi en el estándar de la noche a la mañana.

5. API REST y un manifiesto OpenAPI

Es la opción obvia si eres un SaaS, menos obvia si eres un sitio de contenidos o un comerciante de calle que corre un backend de Shopify. El principio es el mismo en cualquier caso: cada superficie de datos que un usuario pueda ver en tu UI debería estar disponible como JSON vía un endpoint HTTP, y deberías describir esa superficie en un archivo OpenAPI YAML en /.well-known/openapi.yaml.

¿Por qué importa el manifiesto? Porque OpenAI Operator y agentes visuales similares lo buscarán antes de empezar a clicar. Si lo encuentran, caen en llamadas deterministas a la API y la reserva se completa de verdad. Si no, se ven obligados a interpretar tu DOM. Ese es el mundo donde (al menos en mis pruebas) algo como un tercio de las reservas acaban con la fecha equivocada o la moneda equivocada. Lo cual no le sirve a nadie.

En Yubhub escribí la especificación OpenAPI para treinta y pico endpoints: estadísticas, búsqueda, empleos, empresas, todo. Vive en la ubicación conocida y se referencia desde el bloque Dataset de Schema.org en la página de la API (más sobre esto a continuación).

6. Schema.org: la parte descriptiva y la parte ejecutable

La parte descriptiva es lo que la mayoría de gente de búsqueda ya conoce bien. Bloques JSON-LD para Article, Product, Organization, Recipe, Event. A estas alturas es algo muy maduro, bien soportado, procesado por todos, desde Google hasta un proyecto secundario a medio hacer.

La parte ejecutable es donde se pone interesante. Schema.org lleva años teniendo tipos Action: BuyAction, ReserveAction, SearchAction, OrderAction, pero no me da la impresión de que muchos los hayan usado en serio, porque no había un consumidor real de los datos. Ahora lo hay. Los agentes están empezando a leerlos. Un esquema BuyAction puede decirle a un agente el payload POST exacto necesario para añadir un artículo al carrito. Un ReserveAction puede describir el endpoint de reserva, los parámetros requeridos, el método de autenticación. Todo. Una API autodescriptiva incrustada en tu HTML.

Una advertencia: el tráfico a velocidad de máquina sin rate limiting te vacía el presupuesto de CPU en una tarde. Construye primero las reglas del WAF, luego lanza el esquema.

El otro esquema que valoro (y que creo que está subutilizado) es Dataset. En la página de la API de Yubhub publico un bloque Dataset en JSON-LD que lista cada endpoint como una distribución DataDownload. Así es como he hecho la API descubrible para cualquiera (o cualquier cosa) que procese datos estructurados, incluidos buscadores y sistemas de agentes que aún no se han lanzado:

const datasetSchema = {
  '@context': 'https://schema.org',
  '@type': 'Dataset',
  name: 'YubHub Hiring Intelligence API',
  license: 'https://creativecommons.org/licenses/by/4.0/',
  distribution: [
    { contentUrl: 'https://api.yubhub.co/stats/overview',
      description: 'High-level statistics...' }
  ]
};

No cuesta nada lanzarlo. Legible por máquina para siempre.

7. WebMCP

WebMCP es el que más me entusiasma, y he escrito sobre él más extensamente en otro lugar de este sitio, así que lo dejaré corto aquí. WebMCP permite a una página web registrar herramientas directamente con un agente residente en el navegador a través de navigator.modelContext.registerTool(). El agente lee el esquema JSON de la herramienta, llama a la función y la GUI se salta por completo. Sin scrapeo del DOM, sin clics frágiles.

Lo que te compra en la práctica: WebMCP llena el hueco entre «datos estructurados que el agente puede leer» y «el agente puede hacer algo útil en esta página concreta dentro del navegador». Le estás dando al agente un botón que puede pulsar, acotado a la URL en la que está, con acceso completo al DOM y al estado completo de la sesión. Para un usuario con sesión iniciada, eso es importante.

El estado de la especificación, mientras escribo esto: borrador del W3C Community Group, con el respaldo de Microsoft y Google. Está tras un flag en Chrome 146. Vamos temprano, pero esto está pasando. No puedo evitar pensar que la especificación WebMCP más cercana a la final no requerirá que el usuario inicie una petición desde dentro del navegador, pero puedo equivocarme: veremos.

WebMCP en github.com/webmachinelearning: el borrador del W3C Community Group

En Yubhub el scaffold de WebMCP registra herramientas por página. En una página de empleo, la herramienta es yubhub_current_job y devuelve el empleo en markdown. En la página de búsqueda, la herramienta ejecuta la búsqueda.

Aspecto (actual) de WebMCP: prompt desde dentro del navegador para interrogar a una web.

El agente no tiene que adivinar un patrón de URL ni scrapear el DOM: llama a la herramienta que la propia página haya ofrecido. Esto es mucho menos frágil que la conducción visual.

WebMCP mantiene al agente en el navegador. Un servidor MCP independiente es servidor a servidor.

8. El servidor MCP

La opción titular, y la que la mayoría quiere decir cuando dice «deberíamos hacer algo para IA». Un servidor MCP es un proceso de larga duración que expone un conjunto definido de herramientas (funciones, en realidad) sobre un protocolo estándar. Claude Desktop, Cursor, ChatGPT y una lista creciente de otros clientes pueden hablar con él sin ningún pegamento de integración a medida.

El servidor MCP de Yubhub se distribuye como paquete npm. Para usarlo, un desarrollador deja caer esto en su configuración de Claude Desktop:

"mcpServers": {
  "yubhub": {
    "command": "npx",
    "args": ["-y", "@converly/yubhub"],
    "env": { "YUBHUB_API_KEY": "your-yh_-prefixed-api-key" }
  }
}

Eso es todo. Tras un reinicio, Claude puede listar feeds, obtener empleos, disparar ejecuciones de feed, consultar estadísticas: 22 herramientas cableadas, con la autenticación acotada a la clave de API del usuario. Sin web scraping, sin interpretación del DOM, sin tonterías de navegador headless. Los mismos datos que sirve la web, pero una capa por debajo, expuestos de la forma más predecible en la que un agente pueda consumirlos. Esto convierte mi proyecto en un SaaS sin UI: no necesitas visitar la web salvo para registrarte.

Una lista creciente de marcas ya los ha lanzado. Stripe, Shopify y Cloudflare fueron de los primeros para sus plataformas de desarrolladores. Atlassian, Linear y Asana les siguieron para sus productos SaaS. El caso interesante para el retail, y la razón de que exista todo este artículo, es Lastminute.com.

Un caso de prueba de dos industrias que tú y yo usamos

Quería ver cuál es el estado actual de la cosa fuera del pequeño puñado de marcas que se han despertado. Así que elegí dos páginas a propósito, ambas que de verdad usaría si planificara un viaje: alquiler de coches y viajes.

Dos grandes marcas, dos industrias (alquiler de coches y vuelos, respectivamente) donde los agentes personales van a tomar el control del flujo de reserva en un par de años, si no antes. Fui y descargué el HTML renderizado de ambas páginas y le eché un buen vistazo a lo que un agente vería de verdad a su llegada.

Europcar Londres: FAQ útil, inútil para reservar

europcar.co.uk alquiler de coches en Londres: mucho marketing, muy poco para un agente

La página de Londres de Europcar sí tiene algunos datos estructurados. Hay un BreadcrumbList. Hay un ItemList de atracciones turísticas de Londres (Tower of London, British Museum, Buckingham Palace: una elección rara para una página de alquiler de coches, pero bueno). Y hay un FAQPage con respuestas adecuadas sobre permisos de conducir, políticas de combustible, formas de pago. Ese esquema de FAQ es genuinamente útil para un agente que responda a «qué documentos necesito en el mostrador de Europcar».

Pero falta la capa de reserva. No hay RentalCarReservation. No hay Vehicle. No hay Offer. No hay LocalBusiness para la oficina real. No hay ReserveAction. No hay precios, no hay disponibilidad, no hay clases de vehículo. No hay llms.txt, no hay .well-known/ai-plugin.json. El robots.txt es una línea de reglas de disallow y un único enlace de sitemap.

Así que un agente que aterrice aquí puede responder preguntas sobre las condiciones del alquiler, pero no puede reservar un coche. La reserva vive tras un widget de JavaScript que el agente tiene que conducir visualmente. La conducción visual de flujos de alquiler de coches es frágil como ella sola (selectores de ubicación, calendarios, cadenas de desplegables que alimentan más cadenas de desplegables): el tipo de UI donde el agente elige Heathrow cuando dijiste Gatwick, porque el autocompletar se disparó raro.

Europcar no va con retraso por tontos. Van con retraso porque sus datos estructurados se diseñaron para resultados enriquecidos de Google Search, no para agentes que reservan coches. Es un objetivo distinto, una salida distinta. Lo que necesitan es un esquema Vehicle con disponibilidad, un ReserveAction que apunte a un endpoint documentado e, idealmente, un servidor MCP. La primera marca de alquiler de coches del Reino Unido que haga todo eso bien se convierte en la opción por defecto para cada viaje planificado por IA en este país, y de largo.

Búsqueda de vuelos de Momondo: nada de nada

búsqueda de vuelos de momondo.co.uk: shell de SPA, cero datos estructurados en la URL profunda

Momondo está peor, y lo digo como alguien a quien le cae bien Momondo. La URL profunda que probé (LON a NTE en mayo, con un orden especificado, todo lo que un usuario real fijaría) tiene cero JSON-LD en la página. Ninguno. El HTML son 375 líneas, la mayoría bootstrap del bundle de React. Hay una meta description, una imagen Open Graph, y ya está.

Si un agente personal aterriza en esa URL ve el título «LON to NTE, 13/5 - 17/5», una descripción genérica («momondo searches hundreds of other travel sites») y tiene que, o renderizar el JavaScript (lento, caro, frecuentemente bloqueado por los desafíos anti-bot de Cloudflare), o rendirse. Al agente le costará listar opciones de vuelo. No puede leer precios: no puede reservar.

Ese es el patrón en la mayoría de sitios de viajes basados en SPA ahora mismo. La página funciona preciosa para humanos y es invisible para los agentes. La matriz de Momondo (Kayak/Booking Holdings) tiene el músculo de ingeniería para arreglar esto de la noche a la mañana si quisieran. Aún no lo han hecho.

Lastminute: lo lanzaron, pero ¿entendieron por qué?

lastminute.com lanzó su MCP Server for Flights el 20 de enero de 2026

Lastminute.com es el punto luminoso. El 20 de enero de 2026 anunciaron el lanzamiento de un servidor MCP para su inventario de vuelos: la primera gran OTA en lanzar uno. La nota de prensa lo enmarca como «el primer paso de ejecución de una hoja de ruta de infraestructura de IA a varios años», con hoteles y paquetes dinámicos por llegar. El CEO, Alessandro Petazzi, ha sido claro sobre que es una jugada estratégica de supervivencia.

Una pequeña salvedad, porque no tengo información de dentro: no estoy del todo convencido de que entiendan completamente por qué lo han hecho. La nota de prensa se apoya en frases como «AI-powered travel experiences» y «moving beyond generic recommendations», que es un enmarque de marketing, no realmente de ingeniería.

El enmarque de ingeniería sería: los agentes que encuentran un servidor MCP se saltan tu UI visual por completo, así que te conviertes en el proveedor por defecto para cualquier agente que planifique un viaje en un mercado donde la cobertura de MCP es escasa. Es una ventaja comercial gigantesca y defendible. Solo la conservas si sigues construyendo.

Si tratan esto como un momento de nota de prensa y paran, la siguiente OTA construirá un MCP mejor y se los comerá.

La lección para el resto: no lances un MCP y lo des por hecho. Lanza el MCP, el OpenAPI, el esquema Action, la negociación de contenido en markdown, los feeds JSON. Protección por capas. Cada capa cubre las preferencias de un agente distinto. Adquiere el hábito de preocuparte por todo esto porque no va a desaparecer.

El aspecto de Yubhub con casi todo activado

Yubhub.co: los mismos datos, disponibles de seis formas distintas para que un agente los consuma

Yubhub no es un nombre conocido (aún), pero ha sido mi banco de pruebas para recorrerse toda esta pila con las manos. Lo construí primero la API, con solo un MCP para controlarlo, antes de considerar siquiera una UI. El sitio tiene 16.753 empleos activos ahora mismo, extraídos de 288 páginas de empleo de empleadores y reenriquecidos a diario. Cada uno de esos empleos está disponible de seis formas distintas:

• Como página HTML para humanos
• Como markdown vía negociación de contenido
• Como JSON vía la API REST (GET /jobs/{id})
• Como JobPosting en JSON-LD incrustado en la página renderizada
• Como parte de feeds facetados (JSON / XML / RSS) por empresa, ubicación, habilidad, modalidad de trabajo
• Como herramienta expuesta por el servidor MCP independiente (get_job(id))

Obviamente no sé qué superficie usará un agente dado: depende del cliente, del prompt, de los hábitos del usuario, así que prefiero estar disponible en todas a adivinar mal y perder. El coste de hacer esto, una vez tienes la capa de datos bien, es sobre todo trabajo de enrutamiento. Un par de semanas de código de edge function y serializador, en mi experiencia. No un proyecto de hoja de ruta de un año. Es este tipo de cosas lo que da al startup la ventaja: construir para agentes y usuarios, no solo usuarios frente a años de deuda técnica, prioridades y reuniones.

Lo mínimo que merece la pena hacer

Si has leído todo eso y has pensado «sí, pero no tengo tiempo para nada de ello», aquí va una versión mínima viable de la pila:

1. Deja un llms.txt en tu raíz listando tus páginas y feeds más importantes (recuérdales a tu equipo de SEO que hay otros consumidores de este archivo, diles que lo googleen.)
2. Añade negociación de contenido Accept: text/markdown aunque solo sea por razones de ancho de banda
3. Publica un JSON Feed de tu contenido más actualizado
4. Añade Dataset en JSON-LD a tu página de API/datos si la tienes, o esquemas Action si tienes un flujo transaccional

Medio día de trabajo para un ingeniero que conozca tu pila, más o menos. Eso te saca del cuartil inferior y da a los agentes una oportunidad. Cualquier cosa por encima (manifiesto OpenAPI, servidor MCP, WebMCP) es donde empiezas a competir de verdad por el estatus de proveedor por defecto para agentes en tu categoría.

Las marcas que ganen la próxima década no serán las del mejor SEO. Serán las cuyo producto resulte más fácil de comprar por software en nombre de un cliente. Es una disciplina distinta, en un juego distinto, con un tooling distinto, todo motivado por incentivos distintos, y la ventana para volverte bueno en esto está abierta ahora mismo.

Si quieres un ejemplo práctico de cómo encaja la pieza MCP, he escrito sobre construir servidores MCP para Claude Desktop en otro lugar de este sitio. Lee eso a continuación o ponte en contacto. Disfrútalo, ¡me encanta!

---