Licitaciones Públicas ES/UE

Búsqueda normalizada sobre licitaciones del sector público publicadas en TED (Tenders Electronic Daily, la plataforma oficial de anuncios de contratación de la UE) -- cubre España y el resto de la UE. Candidato NEXUS nº 16 -- creación manual, no generado por FORGE, con el mismo patrón manual de Cloud Run Asset que los candidatos nº 3/4/6/8/9/13.

• POST /search-public-tenders {"country": "ESP", "keyword": null, "cpv_prefix": null, "days_back": 30, "limit": 20} -- 0,01 $/llamada.

• Herramienta MCP search_public_tenders en /mcp, mismos parámetros -- actualmente gratuita, ver "Limitaciones conocidas".

• GET /health, GET /.well-known/agent-card.json, GET /openapi.json (tiene x-payment-info), GET /.well-known/402index-verify.txt (archivo de verificación de reclamación 402index).

Fuente: cambio con respecto al informe original, con aprobación explícita (23-08-2026)

El informe de la tarea mencionaba contrataciondelsectorpublico.gob.es/sindicacion/sindicacion_643/ (fuente nacional española de sindicación ATOM del PLACSP) como "ya fundamentado de la sesión anterior". Verificado en vivo al comienzo de esta sesión mediante dos rutas de obtención independientes (curl, WebFetch, con y sin un User-Agent de navegador): 403 Forbidden, y el propio robots.txt del dominio indica Disallow: / para todo el sitio -- un bloqueo declarado a nivel de sitio, no una limitación de frecuencia. Eso muy probablemente también bloquearía Cloud Run (un rango de IP de centro de datos, objetivo común de este tipo de regla WAF). Se avisó al usuario antes de escribir cualquier código (no se sustituyó silenciosamente) -- el usuario eligió cambiar a TED.

TED (Tenders Electronic Daily, api.ted.europa.eu) es la API oficial de búsqueda de anuncios de contratación pública de la propia Oficina de Publicaciones de la UE -- gratuita, sin clave, sin autenticación documentada. Verificada en vivo y campo por campo en esta sesión (una README de terceros tenía nombres de campos de consulta incorrectos en el primer intento -- por ejemplo, afirmaban country-buyer cuando la API real solo acepta buyer-country -- por lo que cada campo/operador a continuación se confirmó contra las respuestas de la API real, no se confió en información de segunda mano):

• POST https://api.ted.europa.eu/v3/notices/search con un cuerpo JSON de query (cadena de búsqueda experta), fields (array de nombres de campos eForms a devolver), limit, scope ("ACTIVE" o "ALL").

• Campos de consulta confirmados en vivo: publication-date>=YYYYMMDD (8 dígitos, sin guiones), buyer-country=ESP (código ISO-3166 alpha-3), FT~"frase" (texto completo), AND, SORT BY publication-date DESC.

• Campos de salida confirmados en vivo: publication-number (número de publicación), notice-title (diccionario multilingüe, claves como spa/eng), buyer-name (diccionario multilingüe de listas), buyer-country, publication-date, classification-cpv (lista de códigos CPV), total-value (no está presente en todos los tipos de anuncios -- por ejemplo, los anuncios de sistema de cualificación no lo llevan, es normal, no un error), notice-type, links (URLs de detalle en html/pdf/xml por idioma).

• Consulta real probada: solo buyer-country=ESP coincidió con 26 314 anuncios en el ámbito ACTIVE en el momento de esta comprobación; una combinación publication-date + buyer-country coincidió con 1 058 en una ventana de 8 días -- volumen real, actual, no un endpoint vacío/desactualizado.

TED ya cubre España (cualquier licitación por encima del umbral de publicación de la UE aparece con buyer-country=ESP) y además del resto de la UE, así que encaja con el enfoque "España/UE" del informe original al menos igual de bien que la fuente nacional de sub-umbral bloqueada -- posiblemente mejor, ya que es paneuropeo por construcción y no está bloqueado. Diferencia de alcance respecto a lo que la fuente bloqueada habría dado: TED solo incluye anuncios por encima del umbral de publicación de la UE (un límite real y no trivial -- las licitaciones nacionales de sub-umbral de España, las que el feed nacional del PLACSP habría incluido por sí solo, NO están en TED). Este activo no pretende cubrirlas; total_matching_notices y el campo source: "TED" de cada resultado hacen explícito el alcance real al comprador, no da a entender que es más amplio de lo que es.

Related MCP server: LexSocket MCP Server

Estado (excepción db_constraint)

Toda activo manual hermano (url-metadata-api, agent-verification-api, document-conversion-api, new-x402-listings-feed, onchain-activity-index, x402-receipt-verifier) es totalmente sin estado -- cada llamada accede a su fuente externa actualizada, sin tabla propia de NEXUS más allá de los triada estándar de telemetría traffic_events/revenue_events/mcp_call_events. Este es el primero de los 8 activos manuales/FORGE que una excepción caso por caso: una nueva tabla, tenders_query_cache, (migración de Supabase add_tenders_query_cache_candidate16, proyecto ieduhdgfjdeffvzxvihf), lectura+escritura solo por este activo.

Por qué: la propia documentación de TED dice que no hay limitación de tarifa documentada pero pide a los llamadores ser razonables con el volumen de solicitudes sobre un recurso público compartido. Guardar en caché las mismas solicitudes repetidas (mismo país/palabra clave/cpv_prefix/days_back/límite, agrupadas por hora) durante 1 hora es ser un buen ciudadano de esa guía, no un estado innecesario -- una acierto de caché se marca "cache_hit": true en la respuesta para que el comprador pueda ver cuando ocurre.

Esto NO es el estado que el diseño original de recogida de PLACSP habría necesitado. Ese diseño (recorrer un fuentefeed ATOM no filtrable, llevar un registro de los IDs de licitación "ya vistos" para detectar deltas -- la misma forma que la caché de recorrido de catálogo de new-x402-listings-feed) no se aplica aquí: el filtrado de publication-date>= del propio servidor de TED ya responde "qué hay nuevo desde X" sin que este activo tenga que recordar nada sobre licitaciones individuales. El único estado mantenido es una caché de respuestas de corta duración, no un índice de licitaciones.

RLS: solo anon recibe SELECT + INSERT sobre tenders_query_cache, no se concede UPDATE/DELETE, misma disciplina de insertar-anexo que cada otra tabla de telemetría de NEXUS. Una "sobregrabación" de caché se convierte realmente en una nueva fila con cached_at más reciente; la consulta de búsqueda siempre elige la fila más fresca dentro de la ventana de TTL. Las filas obsoletas de más de 1 hora de TTL nunca se eliminan -- el crecimiento ilimitado durante la ventana de prueba de 7 días es despreciable (una fila por consulta distinta por hora) y se acepta de momento; una limpieza real requeriría o bien un trabajo programado o un permiso DELETE que este activo no necesita por lo demás.

Objetivo de despliegue: Cloud Run

Misma canalización que los candidatos nº 4/3/6/8/9/13 -- ver skills/infra-deploy-ops.

# 1. First deploy -- PUBLIC_DOMAIN not known yet, every real request 421s until step 2.
./scripts/deploy_cloud_run.sh public-tenders-es-eu manual_assets/public-tenders-es-eu

# 2. Grab the printed *.run.app URL, then (only if it differs from env-vars.deploy.yaml's guess):
gcloud run services update public-tenders-es-eu --region us-central1 --project nexus-505016 \
    --update-env-vars PUBLIC_DOMAIN=<the-real-domain>

Limitaciones conocidas (no corregidas a propósito -- CLAUDE.md SS3, sin puerta de lanzamiento sin evidencia de que se necesite)

• Las llamadas a herramientas MCP no se cobran. Mismo patrón de llamada en proceso que en todos los demás activos manuales de este código.

• Solo licitaciones por encima del umbral de publicación de la UE. Ver "Fuente" más arriba -- las licitaciones nacionales de sub-umbral de España no están en TED y no están cubiertas por este activo.

• cpv_prefix se filtra en el cliente, después de la obtención. La sintaxis de consulta de TED no admite la coincidencia de prefijo de CPV en el servidor; esta pequeña activo obtiene de más (3 veces el límite, con tope en 50) cuando se establece cpv_prefix y luego filtra en proceso. Una llamada con un cpv_prefix muy estricto y una ventana days_back amplia se podría obtener menos coincidencias reales de las que existan en el conjunto de resultados completo de TED más de lo que se sobobtiene.

• La caché es un simple TTL de 1 hora, no se invalida por nuevas publicaciones de TED. Una consulta repetida dentro el mismo bloque de hora puede devolver resultados obsoletos con una antigüedad de hasta ~1 hora respecto a TED. Se informa mediante cache_hit en cada respuesta.

• No hay limitación de frecuencia por llamador. Adecuado para una ventana de medición desechable de 7 días.

• Las filas de tenders_query_cache se eliminan nunca. Ver "Estado" más arriba.

Puerta de calidad (23-08-2026, desde diseño no retroactivo)

Mismo proceso de 2 agentes que los candidatos nº 3/4/6/8/9/13 (lente de seguridad; lente funcional + calidad + experiencia del comprador) -- resultados completados abajo una vez se ejecute.

Medición (candidato nº 16, ventana de 7 días)

Ventana de 7 días desde el 23-08-2026 (fecha de despliegue real) al punto de decisión del 30-08-2026. Fuente de verdad: traffic_events/revenue_events/mcp_call_events (asset_name = 'public-tenders-es-eu'), no registros de Cloud Run. Día 7: si no hay tráfico real (filtrado de escáneres), pausar/eliminar el servicio de Cloud Run (gcloud run services delete public-tenders-es-eu --region us-central1 --project nexus-505016).