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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: a hard result cap in the free tier (10 agencies, 3 names), the full expansion behavior, and the bearer-key requirement for full=true. It stops short of saying what happens with a full=true call that lacks a key.

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?

Two dense sentences, front-loaded with the returned measures before the parameter and tier details. Phrasing like 'how much sits with contractors whose lenders are marking the loan down' takes a second read, but no sentence is filler.

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 output schema, the description carries the return-shape burden and largely does so by naming the three measures, the names included, and the free-tier row limits. The one gap is behavior on a full=true call without a valid key, which an agent would want to know before calling.

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 coverage is 50% — the 'agency' parameter has no description at all in the schema — but the description compensates by explaining it is optional free-text filtering with concrete examples ('Defense', 'Veterans'). The 'full' parameter's meaning and auth requirement are restated from the schema, so the value added is mainly on the undocumented parameter.

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 states a specific resource and unit of aggregation — 'per federal agency' — plus the three measures returned: contractor count, obligations since FY2025, and dollar exposure to contractors whose lenders are marking the loan down. The agency-level framing implicitly and clearly separates it from sibling exposure tools such as exposure_awards (award-level), exposure_institution, and exposure_summary.

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?

It explicitly tells the agent when to use the default call (free preview: top 10 agencies, 3 names each) versus full=true (every agency and every name, requires a Tensorust key), which is real decision guidance. What's missing is any routing against siblings like exposure_awards or lender_marks for related questions.

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