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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable caveats about data provenance (e.g., 'Ballast is not an observed margin call', 'dated structure is not live transit data', 'nothing here is a forecast, trade signal, or Seiche composite input') which clarify the nature of the information beyond the annotations. It also notes that certain items are 'scenario-only' arithmetic, adding transparency about the data's reliability and limitations.

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 a single, dense run-on sentence packed with many semicolon-separated clauses and specialized jargon. While it is information-dense, it is not concise or well-structured for quick comprehension. It would benefit from breaking into separate sentences or bullet points. The sheer volume of detail makes it harder to parse, and every word is not earning its keep due to redundancy (e.g., listing every data category in a list-like manner without clear hierarchy).

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 parameters and an output schema already present, the description's job is to explain the tool's context and content. It extensively lists the data elements and explicitly marks what is scenario-only versus observed, which provides a comprehensive picture. It does not need to explain return values because the output schema covers that. The description is thorough and leaves little ambiguity about what the tool provides, despite being verbose.

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 has zero parameters and an empty schema, so there is nothing to explain. According to the rubric, 0 parameters yields a baseline score of 4. The description does not need to compensate for schema gaps since there are none. It provides a rich description of the data content, which effectively conveys what the tool returns, even though there are no parameters to document.

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 defines the tool's purpose: to provide oil/energy futures transmission context into dollar funding. It enumerates specific data types (WTI/Brent, CP, SOFR-IORB, CFTC positioning, etc.) and explicitly states when to use it ('Use when a question asks how oil or energy futures can transmit cash pressure into dollar funding'). This distinguishes it from sibling tools like 'funding_stress_now' and 'money_market_context' by focusing on oil-specific transmission mechanics.

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 an explicit when-to-use condition ('Use when...') which serves as clear usage guidance. However, it does not explicitly mention when not to use it or suggest alternative tools, but the condition is precise enough. The exclusions (e.g., 'Ballast is not an observed margin call') are more about data interpretation than tool selection, so they don't fully cover usage alternatives.

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