El agente es inteligente. El problema es que la web es sucia.
A las 2 de la madrugada, tu agente de IA se conecta a un sitio para consultar los precios de la competencia. Pero el sitio muestra un CAPTCHA, cambia su estructura HTML y bloquea bots. El agente no se desconcierta. En cambio, inventa algo que parece plausible. El usuario cree que esa alucinación es un hecho.
En el momento en que expones un agente a la web en tiempo de ejecución, estás entregando incertidumbre justo delante de los ojos del usuario.
El núcleo del problema no es "cuánto se recopila". Es cómo se contrata (contract) la interfaz de datos que consumirá el agente. Este artículo no trata sobre rendimiento, sino sobre el contrato de interfaz.
TL;DR
- El verdadero punto decisivo al conectar datos web con agentes de IA y servidores MCP no es la escala de recopilación, sino el diseño del contrato de datos que consumirá el agente (machine-facing interface).
- Si el agente navega directamente en cada llamada, los riesgos de bloqueo, latencia y alucinación se trasladan tal cual a la respuesta. Si consulta feeds previamente depurados como recursos MCP, las respuestas son consistentes y fáciles de citar.
- No cargues la incertidumbre en el tiempo de ejecución del agente; trasládala al contrato de backend. Hash Scraper absorbe la recopilación y la respuesta a bloqueos mediante un backend gestionado, y entrega al agente únicamente feeds contratados.
Índice
- Qué es MCP — el enchufe estándar para agentes
- Dos caminos: navegación directa vs. feeds contratados
- Tabla comparativa: no es rendimiento, sino la ubicación de la responsabilidad
- Escribe el esquema como un contrato — tool y resource
- 4 principios de grounding para evitar alucinaciones
- 5 elementos del contrato para máquinas
- 5 pasos para diseñar la conexión
- 5 preguntas de autodiagnóstico
- FAQ
- Conclusión
- Empieza ahora
Qué es MCP — el enchufe estándar para agentes
Definición 1. MCP (Model Context Protocol) es un protocolo que define cómo los agentes de IA conectan herramientas externas (tool, acciones) y datos (resource, consultas) de manera estandarizada.
Es fácil si imaginas un enchufe. Si la forma de los enchufes fuera distinta en cada país, habría que fabricar adaptadores cada vez. MCP es un enchufe estándar que unifica esa especificación. Basta con que el agente se conecte a este enchufe para comunicarse con cualquier backend de la misma forma.
MCP expone dos tipos de cables. Un tool es una acción de "ejecutar algo", y un resource son datos de "consultar algo". En la conexión de datos web, nos centraremos en el segundo, el resource. Aquí es donde se divide la dirección del diseño.
Dos caminos: navegación directa vs. feeds contratados
Hay dos grandes formas de conectar la web a un agente.
Camino A — El agente navega directamente en cada llamada. Cuando el usuario pregunta, el agente sale al sitio en ese momento. Parece flexible, pero los bloqueos, CAPTCHA, cambios de estructura y latencia del sitio fluyen por completo hacia la calidad de la respuesta. La respuesta a la misma pregunta difiere entre ayer y hoy. Si el sitio bloquea el acceso, el agente no se detiene: inventa algo plausible. Es un caldo de cultivo para las alucinaciones.
Camino B — Consulta feeds previamente recopilados y depurados como recursos MCP. El backend ya terminó la recopilación con antelación, y el agente solo recibe resultados estructurados según el contrato. Las respuestas son consistentes y, al incluir fuentes, fáciles de citar.
La navegación directa es que el agente salga a la naturaleza cada vez; un feed contratado es recibir documentos en una ventanilla depurada.
No lo malinterpretes. No se trata de "cuál es más rápido". Se trata de dónde se acumula la incertidumbre. El camino A acumula incertidumbre en el tiempo de ejecución del agente, es decir, justo delante del usuario. El camino B empuja la incertidumbre detrás del contrato de backend.
Tabla comparativa: no es rendimiento, sino la ubicación de la responsabilidad
Definición 2. Un contrato de datos (data contract) es un acuerdo machine-facing que fija de antemano los campos, tipos, significados y metadatos de los datos que recibirá el agente, para que ambas partes puedan confiar en esa especificación.
| Eje | Navegación directa (camino A) | Feed de recursos MCP (camino B) |
|---|---|---|
| Riesgo de bloqueo | Expuesto directamente en el tiempo de ejecución del agente | Aislado detrás del contrato de backend |
| Latencia | Ocurre en el momento de la llamada, impredecible | La consulta es estable según el feed depurado |
| Coste | Recopilación repetida en cada llamada | Una recopilación, distribuida entre muchas consultas |
| Consistencia de respuesta | Varía en cada llamada | Misma entrada → mismo resultado |
| Riesgo de alucinación | Inventa datos ante fallos | Se reduce al indicar resultados vacíos y fuentes |
| Mantenimiento | La recopilación queda acoplada a la lógica del agente | Gestión separada en la capa de contrato |
Hay una sola conclusión que atraviesa la tabla. La diferencia no está en el eje del rendimiento, sino en la ubicación de la responsabilidad. ¿Cargarás la responsabilidad por bloqueos, latencia y alucinaciones al agente, o al contrato?
Agente ligero, contrato robusto.
Escribe el esquema como un contrato — tool y resource
Para que un contrato genere confianza, su redacción debe ser precisa. Lo mismo aplica a los esquemas de tools y resources de MCP.
Fija los tipos y significados de los campos. Determina en el esquema si price es una cadena o un entero, cuál es la moneda y qué valor representa "agotado". En el momento en que el agente tenga que adivinar el significado de un valor, el contrato se rompe.
Incluye obligatoriamente metadatos que permitan citar. Deben incluirse estas tres cosas.
- URL de la fuente — Para que el agente pueda citar en la respuesta "de dónde viene".
- Hora de recopilación — Para que pueda evaluar e indicar la frescura.
- Identificador (id) — Para volver a consultar el mismo objetivo y eliminar duplicados.
Los datos sin fuente, hora e identificador son, para un agente, como un rumor sin fundamento.
Estas tres líneas de metadatos crean citabilidad (citability). El objetivo del contrato es hacer que el agente responda no "El precio es 12.000 wones", sino "El precio es 12.000 wones (fuente: X, recopilado: hoy a las 9 de la mañana)".
4 principios de grounding para evitar alucinaciones
Las alucinaciones del agente suelen producirse porque, al volver con las manos vacías, no puede decir que no encontró nada. El contrato elimina ese margen.
- Responde con JSON estructurado. No texto libre, sino JSON conforme al esquema. Elimina el espacio para que el agente imagine cosas durante el análisis.
- Obliga a incluir el campo de fuente. Un registro sin fuente infringe el contrato. Evita que datos imposibles de citar aparezcan en la respuesta.
- Indica explícitamente los resultados vacíos. Devuelve "sin resultados" como un valor claro. El silencio provoca alucinaciones.
- Indica la frescura. Entrega también la hora de recopilación para que el agente indique por sí mismo "a qué momento corresponde".
Las alucinaciones no surgen porque los datos sean incorrectos, sino porque se deja al agente rellenar los huecos.
5 elementos del contrato para máquinas
A diferencia de una API para humanos, un contrato machine-facing que un agente llama repetidamente necesita cinco elementos.
- Idempotencia (idempotency) — Aunque se envíe la misma solicitud varias veces, el resultado y los efectos secundarios deben ser idénticos. Es una base esencial en entornos de agentes donde los reintentos son frecuentes.
- rate limit — Controla las avalanchas de llamadas a nivel de contrato y protege tanto al backend como al agente.
- Token y ámbito de permisos — Limita mediante scopes a qué recursos puede acceder cada agente.
- Versionado de esquema — Informa mediante versiones cuando cambian los campos. No modifiques silenciosamente el contrato.
- Convención de errores — Devuelve los fallos con códigos y formatos definidos. Evita que el agente confunda un fallo con "datos vacíos exitosos".
Un contrato demuestra su valor no cuando todo va bien, sino cuando algo sale mal.
5 pasos para diseñar la conexión
- Definir el uso — Primero determina qué hará el agente con estos datos. ¿Comparación de precios o resumen de reputación? El uso determina el esquema.
- Decidir la arquitectura — ¿Navegación directa (camino A) o feed contratado (camino B)? La mayoría de los agentes de producción usan el camino B.
- Finalizar el esquema — Fija los tipos y significados de los campos, y vuelve obligatorios los metadatos de fuente, hora de recopilación e identificador.
- Añadir elementos de contrato — Agrega idempotencia, rate limit, ámbito de permisos, versionado y convención de errores.
- Verificar el grounding — Prueba si los resultados vacíos, los campos de fuente y la frescura se aplican realmente, y si el agente no inventa información.
Una buena conexión no empieza con código, sino con un contrato.
Conviene dejar algo claro. Estos cinco pasos tratan por completo de la capa de contrato de interfaz. El rendimiento de recopilación —"cuánto se recopila y con qué rapidez"— pertenece a una capa distinta, abordada en el artículo [Pipeline de recopilación masiva en tiempo real (023)]. Aquí diseñamos exclusivamente el contrato que consumirá el agente.
5 preguntas de autodiagnóstico
Comprueba si tu conexión entre agente y datos web es realmente un contrato.
- [ ] ¿Los datos entregados al agente siempre incluyen URL de fuente, hora de recopilación e identificador?
- [ ] Cuando no hay resultados, ¿devuelve "sin resultados" como valor explícito? (¿El agente no inventa datos?)
- [ ] ¿La respuesta es JSON con esquema fijo, y no texto libre?
- [ ] ¿Es un contrato idempotente en el que el resultado es igual aunque se repita la misma solicitud? ¿Tiene rate limit y ámbito de permisos?
- [ ] Cuando cambian los campos, ¿informa al agente mediante versión de esquema y convención de errores?
Si solo cumples tres o menos, no has conectado datos: estás cargando incertidumbre en el tiempo de ejecución del agente y entregándosela al usuario.
FAQ
P. ¿Cómo conecto datos web en tiempo real a un agente de IA o servidor MCP?
R. No hagas que el agente navegue directamente por el sitio en cada llamada. Diseña el sistema para que consulte datos previamente recopilados y depurados como recursos MCP. La clave es el contrato de datos. Fija los tipos y significados de los campos, haz obligatorios como metadatos la URL de fuente, la hora de recopilación y el identificador, y luego añade idempotencia, rate limit, ámbito de permisos, versionado de esquema y convención de errores. Lo estable es que un backend gestionado absorba la recopilación y la respuesta a bloqueos, mientras el agente consume únicamente feeds contratados.
P. ¿Cuál es la diferencia entre tool y resource?
R. Un tool es una acción de "ejecutar", mientras que un resource son datos de "consultar". Al entregar feeds depurados en una conexión de datos web, normalmente se exponen como resource. Es más limpio para el contrato separar como tool las acciones que cambian el estado, como activar la recopilación.
P. El agente inventa constantemente datos que no existen. ¿Qué debo corregir?
R. Obliga un contrato de grounding. Responde con JSON estructurado, convierte el campo de fuente en obligatorio, devuelve los resultados vacíos como valores explícitos e indica la frescura mediante la hora de recopilación. Las alucinaciones no suelen surgir porque los datos sean incorrectos, sino porque se deja al agente rellenar huecos.
P. ¿Cómo debo gestionar desde el agente el problema de que los sitios bloquean continuamente?
R. No lo gestiones desde el agente. La práctica correcta es trasladar la respuesta a bloqueos al backend gestionado detrás del contrato. Hash Scraper absorbe la recopilación y la respuesta a bloqueos mediante un backend gestionado, y entrega al agente únicamente feeds ya depurados según el contrato. Es una estructura que no carga incertidumbre en el tiempo de ejecución del agente.
Conclusión
Un agente no está diseñado para soportar toda la web. Soportar la suciedad de la web es tarea del backend, y la tarea del agente es recibir documentos depurados en una ventanilla contratada y citarlos con precisión.
Por eso, el centro de gravedad del diseño no está en "cuánto recopilar", sino en "cómo contratar". Un contrato que fija los campos, incluye fuente, hora e identificador, declara resultados vacíos y cuenta con idempotencia, versionado y convención de errores. Este único contrato empuja las alucinaciones y la variabilidad de las respuestas del agente detrás del backend.
No cargues la incertidumbre en el tiempo de ejecución del agente. Trasládala al contrato de backend. Agente ligero, contrato robusto.
La recopilación y la respuesta a bloqueos las absorbe el backend gestionado. Hash Scraper ofrece recopilación gestionada que absorbe recopilación, respuesta a bloqueos y depuración, y el agente solo tiene que consumir feeds contratados.
Para un contexto más amplio, continúa con Comparativa de servicios nacionales de recopilación de datos (el mapa real de 2026) y El monitoreo no es recopilación, sino notificación — crear un bucle de respuesta con datos de precios y reputación.
Empieza ahora
Si quieres añadir un contrato estable de datos web a un agente de IA o servidor MCP, lo más rápido es comenzar con un backend gestionado que absorba recopilación, bloqueos y depuración. Deja que el agente consuma únicamente feeds contratados y confía la web salvaje al backend.
Hash Scraper absorbe la web salvaje en el backend con experiencia en la recopilación de más de 5.000 sitios nacionales, proxies en 195 países y una precisión del 99,7 %, y entrega al agente únicamente feeds depurados según el contrato. Ha trabajado con más de 500 empresas y ha mantenido 0 problemas legales. Al registrarte, te damos 50.000 créditos.
