Every dataset in the archive, with THE YEARS EACH COVERS, its row count and its size. Call this before answering from prose: it is how you find out whether the archive holds data for the year and subject you are being asked about. 49 datasets covering the town and school budgets, the town ledger, staff rosters, out-of-district placements, elections, and fifteen years of annual town reports.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that the tool returns a complete catalog of 49 datasets with years, row counts, and sizes, which is the key behavioral output for a parameterless listing tool. It does not explicitly state side-effect-free behavior, but the nature of the operation makes that low risk.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the first states what the tool returns, the second says when to call it, and the third summarizes coverage. It is front-loaded with the most important information and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-argument listing tool with no output schema, the description is complete: it states what is listed, the metadata included, the number and subject coverage of datasets, and exactly when the agent should call it. Nothing needed for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline of 4 applies; there is no parameter detail for the description to add beyond the schema. The description's mention of returned attributes is about output semantics, not parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete action and resource: it lists every dataset in the archive with years, row count, and size. It clearly positions itself as an inventory/coverage lookup, which distinguishes it from retrieval or query siblings like document, query, and search_meetings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance: call this before answering from prose to determine whether the archive has data for the requested year and subject. It does not name alternative tools or state when-not-to-use conditions, so it stops just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct concern: dataset discovery, data-grain warnings, safe budget lookups, staff counts, meeting full-text search, provenance, SQL catch-all, and query templates. The one soft boundary is that `query` could theoretically reproduce `budget_history` and `staff`, but the descriptions aggressively warn against naive SQL for those cases, which makes the specialization meaningful.
`list_datasets` and `search_meetings` follow a verb_noun pattern, but the rest mix bare nouns (`document`, `query`, `staff`), compound nouns (`budget_history`), an imperative phrase (`read_first`), and an adjective_noun (`worked_examples`). All names are readable and memorable, but no consistent syntactic convention holds across the set.
Eight tools is well within the ideal 3-15 range for a municipal archive server. Each tool earns its place: discovery, pre-query guidance, arbitrary SQL, two specialized wrappers that exist specifically to prevent costly analytical errors, full-text search over a separate corpus, provenance, and a curated set of executable examples.
The domain is well covered: dataset discovery, data pitfalls, arbitrary read-only querying, meeting document search, and citation. The catch-all `query` tool avoids most dead ends. Minor gaps remain — no full-text search over non-meeting documents like town reports and no bulk export/download dataset tool — but the 250k-row guardrail and publisher URLs partially mitigate these.