Skip to main content
Glama

archive

by org.lunenburgbudgetproject

search_meetings

Which of the 1,422 published town meeting documents contain a word — every board, 2025 onward. Returns the board, the date and a citable URL for each. AN EMPTY RESULT MEANS THE WORD IS NOT IN THE INDEXED DOCUMENTS, which is not the same as nobody having said it: the archive starts in January 2025. It matches words exactly, so plurals are separate terms — search "jersey" and "jerseys" both.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
wordYesA single word, lowercase. Not a phrase.
boardNoOptional board slug, e.g. school-committee

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full disclosure burden, and it succeeds. It explains the critical false-negative behavior ('AN EMPTY RESULT MEANS...'), the January 2025 archive boundary, exact word matching, and pluralization. These are exactly the behavioral traits an agent needs to interpret results correctly.

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 description is front-loaded with purpose, then output, then critical caveats. Every sentence carries useful information and no sentence is wasted. The capitalized warning is loud but intentional and effective.

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?

With no output schema, the description adequately names the return fields (board, date, URL). It also covers scope, empty-result semantics, matching behavior, and the archive start date. The absence of pagination details is minor for a simple search tool.

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?

Since schema_description_coverage is 100%, the baseline is 3. The description adds value by explaining exact-match behavior and pluralization, and reaffirms word-level semantics. Board parameter is already well explained in the schema.

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 identifies the exact operation—searching published town meeting documents for a word—plus the scope ('every board, 2025 onward') and the output ('board, the date and a citable URL'). This is specific and distinctive relative to siblings like query and document.

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

Usage Guidelines4/5

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

The description makes the use case clear: an agent should call this tool when it needs to know which meeting documents contain a specific word. It does not explicitly name alternatives or exclusion cases, but the context is strong enough that an agent will not confuse it with other siblings.

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

All archive toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation4/5

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.

Naming Consistency3/5

`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.

Tool Count5/5

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.

Completeness4/5

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.

Resources