Get full detail on a single Federal Register document by its document number (e.g. '2026-12811'): abstract, action, effective date, comment deadline, CFR references, citation, topics, agencies and links.
| Name | Required | Description | Default |
|---|---|---|---|
| document_number | Yes | Federal Register document number, e.g. 2026-17888. Get one from search_documents or recent_documents. |
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 burden. It clearly indicates this is a read operation (no side effects), but it doesn't disclose potential behavior such as error handling for invalid/unknown document numbers, rate limits, or whether the response is paginated. The description is safe but thin on behavioral caveats.
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?
The description is compact and front-loads the main action. The list of returned fields is useful but slightly long; while it adds clarity, it could be trimmed to key categories. Overall, no waste.
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 single-parameter read tool with 100% schema coverage, the description is nearly complete. It could improve by briefly describing the output structure (e.g., JSON object) and handling of not-found cases, but nothing essential is missing for basic invocation.
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 schema covers the single parameter fully (name, type, required, and a clear example). The description reinforces the parameter by showing a sample document number and telling where to get one. Since schema coverage is 100%, the added context is helpful but not strictly necessary.
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 clearly states the tool retrieves full details for a single Federal Register document by document number. It enumerates the returned fields (abstract, action, effective date, etc.), which sharpens the purpose. It also distinguishes itself from siblings by emphasizing a single document lookup by number, not a search or list.
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?
The description implies usage for fetching details on a specific document and even hints at the alternative when you lack a number: get one from search_documents or recent_documents. However, it does not explicitly state when to avoid this tool or compare it directly with alternatives.
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 has a clearly distinct role: agency lookup, single-document retrieval, executive order search, recent document monitoring, and full-text search. The overlap between recent_documents and search_documents is minimal because one is explicitly for monitoring recent publications while the other is for topic-based search.
Tool names are all lowercase and multi-word names use snake_case, which is predictable. Minor deviations exist: 'document' is singular while other resource-oriented names are plural, and 'search_documents' is verb-led while the rest are noun phrases.
Five tools is an appropriate, focused scope for a Federal Register research server. Each tool covers a necessary capability without redundancy or bloat.
The tool surface covers the core workflow: discover documents via search or recent listings, retrieve full details by document number, filter by agency, and access executive orders. There are no obvious dead ends for the stated regulatory intelligence purpose.