Skip to main content
Glama

Avvia una ricerca documentata

research_start
Read-only

Avvia una ricerca CON CONTO: raccoglie TUTTE le pagine di 1-8 query e restituisce l'ELENCO numerato.

Ogni riga: numero, data, fascicolo e pagina, quanti riscontri, uno o due estratti OCR intorno ai riscontri. Nessun campione: tutte le pagine trovate sono nell'elenco (se lungo, continua con research_list). Poi research_read sulle pagine pertinenti, research_discard (con motivo) su quelle che la riga basta a escludere; research_status mostra lette, scartate e mancanti. modo «tollerante» (normale, SEMPRE per le persone): tutte le parole ovunque nella pagina, con le grafie storpiate dall'OCR e le parole spezzate a fine riga; due parole possono appartenere a persone diverse, e la riga lo mostra. «frase»: parole in fila, solo per verifiche veloci: perde i nomi storpiati («Rosi», «Ros- si» per «Rossi») e non va usata come unica ricerca. Query diverse sono piste in unione; non sommare i totali. Filtri: dal/al = anno o AAAA-MM-GG (data del fascicolo), testata = sigla da list_periodicals. panoramica = pagine per decennio, anno e testata. modalita e caratteri_contesto (400-4000, normale 1800) valgono per la lettura «contesto» e per research_continue. quaderno = nome restituito da notebook_open (solo nel connettore locale): la ricerca entra nel quaderno e le pagine già lette senza riscontri nuovi non si ripetono. Per le query di più parole ogni riga dice dove stanno le parole (di seguito, vicine, stesso punto, sparse); le righe sparse sono corte, con l'estratto intorno alla parola più rara. vicinanza: di norma NON usarla (sulle dieci domande di prova l'elenco senza filtro conteneva tutte le 102 pagine giuste ed era di 25-260 righe). Se l'elenco di piste «luogo + fatto» è molto lungo, vicinanza="punto" tiene le pagine con le parole nello stesso punto e conta le escluse (prova: una pagina giusta persa su 102, elenchi più corti del 30-60%); «vicine» è più stretta (tre perse). Vale per TUTTE le piste della chiamata: le piste su una persona vanno in un research_start a parte, senza vicinanza (le pagine sparse contengono nomi abbreviati e parenti). Dichiarala nel resoconto. piano = riferimento da passare agli altri strumenti, valido nel processo per massimo 24 ore (il servizio tiene un numero limitato di ricerche). Nel servizio HTTP può essere espulso per capacità: sessione dichiara la politica. confronto_piste calcola le appartenenze; research_list(piste_esatte=...) elenca una partizione.

Input Schema

NameRequiredDescriptionDefault
alNo
dalNo
modoNotollerante
testataNo
modalitaNoriscontri
quadernoNo
ricercheYes
vicinanzaNo
caratteri_contestoNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Well beyond the annotations: the description discloses that the returned "piano" reference is valid for at most 24 hours, that the service caps the number of stored searches, that HTTP sessions may be evicted for capacity, and that quaderno only exists in the local connector. These are exactly the operational constraints an agent cannot infer, and they are consistent with idempotentHint=false.

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

Conciseness3/5

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

Purpose is front-loaded, but the body is an undifferentiated wall of clauses mixing parameter docs, workflow, and empirical benchmark anecdotes ("sulle dieci domande di prova... 25-260 righe"). Those statistics support the guidance but cost significant length for marginal decision value.

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

Completeness1/5

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

For a 9-parameter, multi-step research tool this should be more structured, and the phantom "panoramica" and "confronto_piste/piste_esatte" references (neither in schema nor in sibling tools) leave the picture incomplete. It also acknowledges the output schema exists yet still spends text re-describing the row format.

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?

With 0% schema description coverage the description carries the full burden and mostly delivers: dal/al accept a year or AAAA-MM-GG on the fascicolo date, testata is a code from list_periodicals, caratteri_contesto is 400-4000 with default 1800, modo/modalita/vicinanza/quaderno are all explained. However it also references a "panoramica" option that does not exist in the schema, which could mislead an agent trying to set it.

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 first sentence states a specific verb and resource ("Avvia una ricerca CON CONTO") and defines both the input scope ("TUTTE le pagine di 1-8 query") and the output ("l'ELENCO numerato"). It also implicitly separates this tool from research_continue/research_list/research_read by describing what they each do next.

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?

Explicit workflow routing is given: after this call use research_read on relevant pages, research_discard with a reason on excludable ones, research_status to see read/discarded/missing. It also states when NOT to use options — "frase" should not be the only search, and "vicinanza" should normally not be used at all, with quantified consequences.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources