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

Annotations already cover read-only, non-destructive, closed-world, so the description's job is to add more — and it does: it discloses the upstream source (USAspending bulk pull), the date floor (Oct 1 2026), sort order, and critically a tiering gate where unauthenticated calls return only count and dollars while a Tensorust key unlocks rows. It does not state row caps or pagination, which keeps it from a 5.

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?

Scope, source, ordering, and access tier are front-loaded in the first clause, and every clause carries information. It is dense to the point of being run-on, though — the colon-delimited field list and the 'tier and dollars per participant' phrase read as compressed shorthand rather than prose.

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?

With no input parameters and no output schema, the description must carry the return shape itself, and it enumerates the fields (award, PIID, office, PSC, set-aside, obligation, action date, tier, dollars per participant) plus the free-tier subset. What is missing is volume and paging expectations for a potentially large award list.

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 takes no parameters, so there is no parameter semantics to document and the baseline applies. The description instead spends its words on the return shape, which is the right allocation for a zero-argument tool.

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?

Names a concrete resource and scope: set-aside labor/R&D actions in FY2027 held by firms in the Performance Ledger review queue, ordered newest first. It is specific enough to separate from perf_summary/perf_firm by implication, but it never names those siblings, so the differentiation is inferred rather than stated.

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 scope sentence implies when this applies (recent FY2027 flow against flagged firms), and the free-vs-key clause implies a preview/verification use case. There is no explicit when-not guidance and no pointer to perf_queue or perf_summary for the adjacent questions, so an agent must guess which of the four perf_* tools to pick.

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