OpenPublica

Get document metadata

get_document

Read-only

One document's metadata. Use read_document_pages to read it.

If an `availability` key is present, read it before quoting figures: its
`problems` are transcription-lint findings, most often a footnote marker
that may have been merged into the number it annotates. No such key means
the document transcribed cleanly.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`document_id`	Yes	Document id from list_government_documents or search_documents.

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, so the description doesn't need to restate safety. It adds meaningful context about the availability key and its transcription-lint findings, which is a subtle behavioral nuance an agent needs to handle figures correctly. It stops short of describing the full return shape or error behavior, but that's acceptable for a read-only metadata tool.

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?

Three sentences, each earning its place: the first states the core purpose, the second points to the sibling for reading, and the third gives a specific, important caveat about the availability key. Front-loaded and economical with no filler.

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 single-parameter metadata getter with no output schema, the description covers the essential behavior: what it returns, how to read the actual content via an alternative, and a critical nuance about transcription-lint findings. It doesn't enumerate all possible metadata fields, but that isn't necessary for correct invocation. A solid, complete description for this level of complexity.

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

Parameters3/5

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

There is only one parameter, document_id, and the schema already provides a 100% description (stating it comes from list_government_documents or search_documents). The description adds no additional semantics beyond what the schema provides, so a baseline of 3 is appropriate.

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 clearly states it returns 'One document's metadata,' using a specific verb and resource. It directly distinguishes itself from read_document_pages by saying 'Use read_document_pages to read it,' making the division of responsibilities unambiguous.

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 explicitly names the alternative tool (read_document_pages) and specifies when to use that instead. It also provides a conditional usage instruction about the availability key, telling the agent to read it before quoting figures. This is precise, action-oriented guidance that leaves no ambiguity.

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

All OpenPublica tools Inspect

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.4/5.0

Disambiguation5/5

Each tool targets a clear, distinct operation: government discovery, meeting search, transcript search, document listing, and document reading are all cleanly separated. The three find_governments tools overlap in purpose but are differentiated by input type (name, ZIP, coordinates), and the descriptions explicitly call out when to prefer one over another.

Naming Consistency5/5

Tool names follow a consistent and predictable verb_noun pattern: find_governments_by_*, get_*, list_*, search_*, read_*, and discover_*. The qualifiers are descriptive and parallel, making the intended action and resource obvious from the name alone.

Tool Count5/5

At 15 tools, the set is at the upper end of the ideal range but every tool earns its place by covering a distinct capability across two related domains: meetings and government documents. There is no filler or redundancy; the count feels well-scoped for the server's stated purpose.

Completeness5/5

For a read-only public-records service, the surface is remarkably complete: government resolution by name/ZIP/coordinates, coverage, stats, meeting discovery/search/retrieval, transcript-level search, and document listing/search/reading all have dedicated tools. There are no obvious dead ends—every search path leads to a retrieval tool that can produce citable quotes, pages, or full transcripts.

Resources

Need Help?