Skip to main content
Glama

sincronizar_indice

Starts background synchronization of the local index of official bulletins, updating missing and recent entries. Returns immediately with status; only one sync runs per index source.

Instructions

Arranca en segundo plano la sincronización del índice local de sumarios y vuelve al instante.

origen: "bomemelilla.es" (por defecto, el sitio actual) o "melilla.es" (el portal antiguo). Solo corre una a la vez por índice, sea del origen que sea: si ya hay una sincronización en curso (de cualquiera de los dos, en este u otro proceso) devuelve su estado o en_curso_en_otro_proceso con el origen que la ocupa, sin arrancar otra.

origen="bomemelilla.es": recorre el calendario (por defecto 2018-01-01..hoy) del más reciente al más antiguo: indexa los boletines que falten, re-indexa los de los últimos reindexar_recientes_dias días y, si reintentar_errores, los que fallaron. Empieza en 2018 porque antes bomemelilla.es está incompleto e inestable (faltan boletines y sus páginas rotas responden HTTP 500, que el cortafuegos castiga) y apenas tiene texto buscable; los boletines anteriores se consultan mejor en el portal antiguo de melilla.es. Un 'desde' anterior es posible pero no recomendable. Para no saturar el sitio va despacio (~2-3 s entre peticiones) y cada ejecución indexa como mucho max_boletines boletines (por defecto 250, los más recientes; ~15-20 minutos). El rango por defecto (~1100 boletines) necesita varias ejecuciones: si el estado final trae pendientes_tras_limite > 0, vuelve a llamarla más tarde (espaciar las ejecuciones es más amable con el sitio). Es reanudable: si se corta, la siguiente llamada continúa donde quedó. Sigue el progreso con estado_indice; mientras tanto buscar_en_indice da resultados parciales. Si ya hay una en curso (en este u otro proceso) devuelve su estado sin arrancar otra. Solo sincroniza cuando se le pide. El cortafuegos del sitio bloquea la IP tras unas 5 respuestas de error, así que la sincronización admite como mucho 3 cada 10 minutos (si llega al límite hace una pausa preventiva y va más lenta) y espera 30-60 s tras una página rota (valores por defecto; los que están en uso, en estado_servidor, 'ajustes'). Si el sitio la bloquea (403/429/503 o dos peticiones seguidas sin respuesta) termina en estado "bloqueado" y bome-navaja no le pide nada durante reintentar_tras_segundos (~75 min): no la relances antes (terminaría "bloqueado" al instante). Los boletines "rotos" (su página respondió con error interno, HTTP 500, dos veces) se saltan; reintentar_rotos=True los vuelve a pedir: úsalo solo para comprobar si el sitio los arregló, porque cada uno cuesta un HTTP 500 que el cortafuegos del sitio cuenta.

origen="melilla.es" indexa los sumarios de artículos de las fichas de boletín del portal antiguo: por defecto los boletines de 1991-01-01 a 2017-12-31 (antes de 1991 las fichas no traen artículos; desde 2018 manda bomemelilla.es), del más reciente al más antiguo, y se salta los que ya están indexados con sumarios desde cualquiera de los dos orígenes. Una petición por boletín (la ficha, nunca los PDF), igual de despacio (~2-3 s entre peticiones) y con el mismo límite max_boletines (por defecto 250, ~15-20 minutos por ejecución): los ~2.000-2.500 boletines del rango necesitan varias ejecuciones espaciadas (mira pendientes_tras_limite). Es reanudable, reintenta los fallidos si reintentar_errores y los rotos solo con reintentar_rotos. reindexar_recientes_dias no se aplica (el portal está congelado). El portal antiguo tiene su propia guardia (guardia_portal_antiguo): sus errores no cuentan para bomemelilla.es. Rellena también los boletines de 2014-2016 que bomemelilla.es tiene sin sumarios.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
desdeNo
hastaNo
origenNobomemelilla.es
max_boletinesNo
reintentar_rotosNo
reintentar_erroresNo
reindexar_recientes_diasNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.0.4

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses asynchronous behavior, one-at-a-time execution, resumability, rate limiting (~2-3 s between requests), firewall blocking behavior, retry semantics, and what happens if a sync is already running. It even explains the blocked state and why relaunching early fails instantly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core behavior and well organized by origin, but it is long and contains some redundancy: 'Si ya hay una en curso' appears twice, and details like 'del más reciente al más antiguo', 'Es reanudable', and 'max_boletines (por defecto 250, ~15-20 minutos)' are repeated across both origin sections. Still, nearly every sentence adds operational value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, no output schema, and 7 parameters, the description is exceptionally complete. It covers defaults, time estimates, failure modes, rate limits, blocking, retry behavior, resumability, partial results, and even where to find current settings (estado_servidor, 'ajustes'). An agent has enough context to invoke the tool correctly and interpret its outcomes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must fully compensate, and it does. Every parameter is semantically explained: desde/hasta ranges per origin, origen variants, max_boletines default and per-execution limit, reintentar_errores, reintentar_rotos with its caveat, and reindexar_recientes_dias including the note that it does not apply to melilla.es.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Arranca en segundo plano la sincronización del índice local de sumarios y vuelve al instante.' It clearly distinguishes this from siblings like estado_indice and buscar_en_indice by emphasizing that it starts a background sync and returns immediately. The two origins are also explicitly named, leaving no ambiguity about what the tool operates on.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use and when-not-to-use guidance: 'vuelve a llamarla más tarde' if pendientes_tras_limite > 0, 'no la relances antes' after a block, and 'úsalo solo para comprobar si el sitio los arregló' for reintentar_rotos. It also points to alternatives: 'Sigue el progreso con estado_indice; mientras tanto buscar_en_indice da resultados parciales.'

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.