Federal Grant Evidence

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond that: 'the current preview is always free' and it 'explicitly marks unresolved project relevance, document, or award-history evidence.' These details tell the agent what behavior and output characteristics to expect without contradicting the annotations.

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 with no filler. The primary use case is front-loaded, followed by cost/behavioral details and explicit negative boundaries. Every clause contributes to correct tool selection and invocation.

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?

Given the tool has two required parameters, an output schema, and strong annotations, the description covers purpose, usage boundaries, and behavioral expectations comprehensively. The schema documents the parameters, the annotations cover safety and idempotency, and the description fills in the strategic when/why context.

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 50%, with opportunity_id documented in the schema and organization not individually described. The tool description adds meaning by specifying that organization is a 'non-personal organization profile' and that the analysis uses the 'official opportunity record,' which maps to the two required parameters. It does not enumerate the nested organization fields, but the property names and enum values in the schema remain self-explanatory.

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, meaningful purpose: a 'sourced go/no-go pursuit screen for one U.S. federal grant' using a non-personal organization profile and the official opportunity record. This clearly distinguishes it from the sibling search_federal_grants and get_federal_grant_evidence_pack tools by emphasizing one-grant screening rather than discovery or evidence retrieval.

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 explicitly tells the agent when to use the tool ('when the user needs a sourced go/no-go pursuit screen') and when not to use it ('Do not use it for discovery only, legal eligibility advice, award prediction, drafting, or submission'). It does not name an alternative tool directly, but the exclusions strongly imply search_federal_grants would serve discovery, so usage guidance is clear and actionable.

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

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

Annotations already carry idempotentHint=true and destructiveHint=true, but the description adds critical context: paid tool with USD 0.09 pricing, Base Sepolia testnet rail, no charge on incomplete records, safe retries with request_id replay, and non-behaviors like not evaluating relevance or eligibility. It doesn't explicitly describe what destructive effect occurs, but the financial charge disclosure covers the main risk.

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?

Five dense sentences, front-loaded with the primary usage condition and outcome. Every sentence earns its place: pricing, testnet limitation, no-charge condition, non-goals, and retry behavior. No tautology or restatement of schema fields.

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 paid, side-effectful tool that has an output schema, the description covers usage, exclusions, billing, and retry semantics well. It misses a definition of what 'hard-gate' evidence means and what the organization parameter is required for, but overall an agent has enough to select and invoke it safely.

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 already documents request_id and opportunity_id, covering 67% of top-level parameters. The description reinforces request_id reuse but adds no meaning to the organization parameter, which is the only undocumented top-level parameter and the most complex nested object. With no description of entity_type, state, requested_amount_usd, or can_meet_cost_share, the description doesn't compensate for that gap.

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 verb and resource: 'get' a 'complete, versioned hard-gate and award-history evidence pack for one U.S. federal grant.' It clearly distances itself from siblings by saying it is used after search/free preview and by explicitly listing non-goals (no semantic relevance, eligibility, award prediction), which aligns with analyze_federal_grant.

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 gives explicit when-to-use guidance: 'only after search or the free preview, when the user wants a complete, versioned... evidence pack.' It also defines exclusions via non-goals. However, it never names analyze_federal_grant as the alternative for semantic evaluation, so the when-not guidance is implied rather than fully explicit.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context by noting that results include current or forecasted opportunities and official identifiers/source URLs, going beyond structured metadata.

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?

Three concise sentences front-load the primary use case, follow with the return value, and end with exclusions. Every sentence contributes essential guidance with no 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 a rich output schema, clear annotations, and a 2-parameter input schema, the description covers the main decision points: when to use the tool, what it returns, and what it should not be used for. No critical context is missing for correct 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?

Schema description coverage is 100%, so the schema already documents both parameters. The description's phrase 'by topic' aligns with the query parameter but does not add meaningful details beyond what the input schema provides, so a baseline score is appropriate.

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 concrete action ('find current or forecasted U.S. federal grant opportunities by topic') with a clear resource and scope. It also clarifies the tool's output (official identifiers and source URLs), which distinguishes it from siblings like analyze_federal_grant and get_federal_grant_evidence_pack.

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 says 'Use this when the user needs to find...' and gives clear when-not cases: 'Do not use it to decide eligibility, predict an award, write an application, or submit anything.' However, it does not name alternative sibling tools, so the routing guidance is strong but not fully complete.

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