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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so 'Read-only' earns nothing. What the description adds is genuinely useful and not in the annotations: an expected latency (~7 seconds), hard result caps (2,000 NIH records or 600 NSF awards), and the disclosure that wider queries return a partial-marked result with an accompanying note.

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 aggregation purpose, then the source filters, then the performance and truncation caveats. No filler sentences and no restatement of the title.

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 does the work of describing the return shape (counts, dollar totals, partial flag plus note) and the cost/limits. Only gaps are the undocumented keyword parameter and the precise semantics of omitting state versus supplying it.

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 40% and only fiscal_year_from/to carry descriptions (their defaults). The description compensates partially by explaining what the state parameter does to grouping and how agency maps to each upstream source's filter syntax, but keyword is undocumented in both schema and description, and the state-as-grouping phrasing is slightly ambiguous.

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?

States a specific verb (aggregates) plus the resource (SBIR/STTR awards) and the aggregation axes (counts and dollar totals by fiscal year, and by state). It also names the two upstream sources with their exact filter mechanics (NIH activity codes R43/R44/R41/R42; NSF fundProgramName SBIR OR STTR), which cleanly separates it from the search_nih_awards / search_nsf_awards siblings.

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?

Usage is implied rather than stated: 'aggregates ... counts and dollar totals' suggests the summary role versus the raw-search siblings, but no sibling is named and there is no explicit when-to-use / when-not-to-use rule. The state-grouping behavior is described, but that is a behavior note, not routing guidance.

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 declare readOnly/openWorld/idempotent/non-destructive, so the bar is lower, and the description still adds real behavioral context: the default activity-code filter (R43/R44/R41/R42) that silently shapes results, the row granularity caveat that a multi-year project can appear more than once, and that every result links back to RePORTER. It stops short of noting rate limits, auth, or pagination behavior.

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 short, front-loaded sentences: scope, then default-filter gotcha, then result-shape caveats. 'Read-only' is a slight duplication of the readOnlyHint annotation, but otherwise each line carries information an agent needs.

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, 11 parameters, and low schema coverage, the description covers purpose, default filtering, and result granularity but omits pagination guidance (offset max 14999), the []-for-all-activity-codes escape hatch beyond the schema, and any auth/rate-limit expectations. Adequate for selection, thin 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 only 36% across 11 parameters, so the description is expected to compensate, yet it only restates the activity_codes default that the schema already documents. Nothing is said about text matching, limit/offset bounds, institutes, org_states, or fiscal year filters, leaving most parameters without added 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?

States a specific verb and resource ('Searches funded NIH projects in NIH RePORTER v2') and immediately pins the default scope to SBIR/STTR activity codes, which naturally separates it from siblings like search_nsf_awards and search_open_opportunities. An agent can tell what this returns without opening the schema.

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?

Usage is implied by the scope statement (funded projects, not open opportunities) and the default-filter note, but no explicit when-to-use/when-not guidance or named alternatives are given despite four siblings in the same family. The agent must infer routing from the 'NIH funded projects' framing.

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 declare readOnlyHint, openWorldHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds real context beyond that: the upstream API, the implicit SBIR/STTR filter applied by default, and NSF's OR-between-words keyword behavior. Rate limits, pagination behavior (offset caps at 2999), and result shape are not disclosed.

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?

Four short sentences, front-loaded with the read-only signal and zero filler. The closing 'Every result links to NSF' is the weakest sentence but still conveys an output detail, which matters given no output schema.

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?

Covers source, default filter, and keyword syntax for an 8-parameter tool, but with no output schema and half the parameters undocumented, it says nothing about result fields, page-size limits, or how include_abstract changes the response. Adequate but with clear gaps for a search tool of this breadth.

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 only 50%, and the description compensates where it matters: it explains that sbir_sttr_only defaults on (why results are SBIR/STTR-heavy) and clarifies NSF's multi-word OR semantics beyond the schema's generic 'supports AND, OR, NOT' note. It leaves rows, offset, and include_abstract entirely to the bare schema.

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?

States a specific verb (Searches) and resource (NSF awards) plus the exact backend (NSF Award Search API on Research.gov). The resource scope inherently separates it from search_nih_awards, search_open_opportunities, and agency_sbir_summary without the agent opening any schema.

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?

No when-to-use, when-not-to-use, or named alternative appears. The default SBIR/STTR scoping hints at a typical use case but is framed as behavior, not routing guidance, so the agent gets no help choosing between this and its four siblings.

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 declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description does add real context beyond them — that coverage spans forecasted and posted records and that each result links to its Grants.gov page — but says nothing about pagination behavior or result size, which is the main behavioral unknown for a search tool.

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?

Four short sentences, front-loaded with the read-only signal and then purpose, usage and output note. Efficient overall, though the leading 'Read-only.' partially duplicates readOnlyHint=true already supplied as structured data.

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?

There is no output schema, so the description carries the burden of describing returns; it does so only in one line ('every result links to its Grants.gov page') and never explains pagination across rows/offset, which matters for a 6-parameter search tool. Purpose and basic usage are covered, but the operational guidance is thin.

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 67%: agency, status, keyword and eligibility are well documented in the schema (eligibility even enumerates all codes), while rows and offset carry no descriptions. The description adds no parameter-level meaning at all; the undocumented pair are self-evident pagination fields with defaults and bounds, so this is baseline-adequate rather than deficient.

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?

States a specific verb and resource — searching forecasted and posted funding opportunities on Grants.gov — plus the backing API (search2) and result shape. It implicitly separates itself from the award-search siblings by scoping to 'open opportunities,' but it never names a sibling explicitly, so it falls short of full differentiation.

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?

'Use it to find open SBIR/STTR solicitations and other grants' gives a clear intended scenario, which is stronger than nothing. However, there is no when-not guidance and no reference to the sibling tools (search_nih_awards, search_nsf_awards, agency_sbir_summary), so the agent must infer the boundary between opportunity search and award search.

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 declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: the tool fans out to two external award databases and the returned scores are a naive keyword overlap rather than semantic similarity, which is a material caveat about result quality that no annotation conveys.

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 tight sentences with the safety marker front-loaded, then the mechanism, then the scoring caveat — no padding. The leading 'Read-only' duplicates the readOnlyHint annotation, a small redundancy, but the ordering is otherwise well front-loaded.

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 does the necessary work of describing the return conceptually (ranked funded projects with overlap scores) and warns that those scores are not semantic judgments. It stops short of describing result fields or empty-result behavior, but an agent has enough to call it correctly.

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?

At 60% schema description coverage, three of five parameters (description, sbir_sttr_only, fiscal_year_from) are documented in the schema. The description reinforces that the `description` parameter drives keyword extraction and clarifies that it covers both NIH fiscal years and NSF award years, but says nothing about `limit` or `sources`, leaving the coverage gap unclosed.

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 gives a concrete verb chain (extracts key terms, searches NIH RePORTER and NSF Award Search, ranks by term overlap) over a specific resource (funded projects), so the mechanism is unambiguous. It implicitly separates itself from single-source siblings like search_nih_awards and search_nsf_awards by searching both and ranking rather than just listing, but no sibling is named explicitly, which keeps it short of a 5.

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 trigger condition is implied by 'Given a project description or keywords,' which tells the agent what input shape to supply, but there is no explicit when-to-use statement, no when-not-to-use, and no routing guidance against the sibling award-search tools. Usage is inferable but not spelled out.

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