Skip to main content
Glama
jgarcialaneitor

bome-navaja

by jgarcialaneitor
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

buscar_en_indice

Search the local index of Melilla official gazette summaries to find articles by text, date, council, or custom terms without accessing the live site. Requires prior index synchronization.

Instructions

Búsqueda instantánea de artículos en el índice local de sumarios (sin tocar el sitio).

Requiere haber llamado antes a sincronizar_indice; si el índice está vacío devuelve 0 resultados y un aviso (usa buscar_articulos mientras tanto). Mira 'cobertura' (rango indexado, pendientes, sincronización en curso) antes de afirmar que algo no existe. La sincronización por defecto cubre desde 2018-01-01: 'pendientes' cuenta solo boletines desde esa fecha y pendientes_anteriores_2018 los anteriores del calendario sin indexar (bomemelilla.es está incompleto antes de 2018; esos boletines se consultan mejor en el portal antiguo de melilla.es). Incluye también los boletines del portal antiguo (melilla.es, 1991-2017) una vez sincronizados con sincronizar_indice(origen="melilla.es"): cada artículo trae 'origen' ("bomemelilla.es" o "melilla.es"); en los de melilla.es, url es la ficha del boletín en el portal antiguo, pdf_url el PDF de la página del artículo (léelo con leer_pdf(url=...)), bome_cve el identificador del portal (antes de 2014 no es un CVE de bomemelilla.es) y cve una clave interna MEL--. cobertura.por_origen da lo indexado de cada origen. Un boletín que está en los dos sale una sola vez, del origen con mejor resultado (con sumarios gana; a igualdad, bomemelilla.es). coincidencia: "fragmento" (subcadena, como el sitio: "cese" encuentra "ceses" y "procese") o "palabra" (cada frase debe empezar una palabra: "cese" → cese, ceses, no procese). terminos=[{texto, operador: "y"|"o", modo: "contiene"|"no_contiene"}]; Y dentro del mismo artículo. consejeria: parte del nombre (sin tildes). orden: "fecha" o "relevancia". Pagina con limite (máx. 200) y desplazamiento ('siguiente' da el próximo). Solo cubre sumarios: de bomemelilla.es desde finales de 2016 y del portal antiguo desde ~1991.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
desdeNo
hastaNo
ordenNofecha
textoNo
limiteNo
terminosNo
consejeriaNo
coincidenciaNofragmento
desplazamientoNo
extraordinarioNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.0.4

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations and no output schema, the description carries the full burden and goes beyond it: it discloses empty-index behavior, index coverage semantics, duplicate resolution (which origin wins), matching modes with examples, AND semantics for terminos, pagination max, and scoping to summaries only.

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

Conciseness5/5

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

The text is long, but every sentence carries operational value: prerequisites, coverage, duplicate handling, matching semantics, and limits. It is front-loaded with the core purpose and flows logically from setup to result interpretation, so the length is justified.

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

Completeness4/5

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

For a 10-parameter tool with no annotations or output schema, the description is unusually complete: it covers prerequisites, alternatives, return-field meanings, edge cases, and pagination. It still leaves a few input parameters and the full result envelope unspecified, which prevents the top score.

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

Parameters4/5

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

Despite 0% schema coverage, the description explains coincidencia values, terminos structure, consejeria matching, orden values, and pagination with max limit. It leaves desde, hasta, and especially extraordinario unstated in explicit terms, so it is not a perfect 5.

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 opening line identifies the tool as immediate search of articles in the local summaries index and explicitly says it does not touch the site. It differentiates itself from siblings such as buscar_articulos and states its coverage limits (summaries only, specific date ranges).

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?

It gives an explicit prerequisite (call sincronizar_indice first), tells the agent what to do if the index is empty (use buscar_articulos), and says to check cobertura before concluding something does not exist. It also names the alternative for pre-2018 bulletins (old melilla.es portal).

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

Deploy Server

Other Tools