rti_overdue

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

With no annotations, the description carries the full burden. It discloses that results are returned 'oldest first with the number of days elapsed,' which is useful. However, it does not explain the effect of the `refresh` parameter or any caching behavior, which is a significant gap for a tool that likely fetches data. It also does not mention whether the tool is read-only (though implied).

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 two sentences, front-loaded with the main action, then adds context and a practical use case. Every sentence earns its place, with no fluff or redundancy. It is concise yet informative.

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?

The description covers the core functionality, legal context, and return behavior, but it fails to mention the `refresh` and `category` parameters, which are essential for understanding the tool's full capability. Given that an output schema exists, return values need not be detailed, but parameter semantics are left incomplete. The tool is moderately complex, so these gaps impact completeness.

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?

Schema description coverage is 0%, so the description must compensate. It explains `days` (defaults to 30 and serves as the overdue threshold). However, it does not explain `refresh` or `category`, leaving these parameters ambiguous. This is a major omission since the description is the only source of parameter meaning.

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's function: 'Pending RTI requests whose reply is overdue.' This distinguishes it from sibling tools like rti_list or rti_search, which do not focus on overdue filtering. The specific reference to the RTI Act's 30-day reply window further clarifies the tool's purpose.

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 provides a concrete use case: 'use it to decide which applications are ripe for a first appeal.' It explains the default threshold (30 days) and implies that this tool is for identifying overdue requests, distinguishing it from general listing tools. It lacks an explicit 'when not to use' but gives sufficient context for appropriate invocation.

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