AI Arena Agent Tools

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is fully covered externally. The description adds only the informational payload (free-beta flag, pricing tiers) and says nothing about auth, rate limits, or whether the beta flag affects 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?

A single front-loaded sentence with no filler. The most useful information (what fields are returned) comes immediately after the verb+resource.

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 correctly compensates by naming the three values an agent will get back. It stops short of describing the response shape or format, but for a trivial zero-param status call that omission is minor.

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 zero parameters, so per the rubric the baseline is 4. There is nothing for the description to clarify beyond confirming this is a no-argument lookup, which the empty schema already conveys.

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 ('Check') and resource ('AI Arena') and enumerates the concrete pieces of information returned: version, free-beta mode, and pricing tiers. Sibling tools are all unrelated SEC/tender/award tools, so no differentiation is needed. Slightly short of 5 only because 'Check' is a generic verb.

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 explicit when-to-use statement, no prerequisites, and no alternatives named. However, for a zero-parameter status endpoint the intended usage (query current service/version/pricing state) is strongly implied by the name and description. Minimum-viable 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/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds the 'FREE beta' pricing/availability note and 'quickly' implies a lightweight fast path, which is useful context. It does not disclose rate limits, result freshness, or what 'flags' returns, so it stays at baseline.

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 compact fragments with the availability note front-loaded and zero filler. It is efficient, though the extreme brevity is what creates the coverage gaps above rather than a deliberate trade-off.

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 and no annotation of return shape, yet 'flags' is never explained — the agent cannot tell whether this returns forms, booleans, or scores. For a tool whose entire value is its output, the description omits the essential detail.

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%: cik is documented in the schema while limit (1-500) has no description anywhere. The description mentions no parameters at all, so the meaning and defaulting behavior of limit is left entirely unexplained; with a simple two-parameter surface this is merely adequate.

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 concrete verb ('flags') and a named resource ('recent filing forms') narrowed to corporate-action categories (tenders, offerings, proxies, material events). The purpose is clear, but it never differentiates itself from the sibling sec_recent_filings_basic or explains the 'basic' vs 'evidence' pair, so it stops short of 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?

Provides no when-to-use guidance, no prerequisites, and no mention of alternatives. The _basic/_evidence sibling naming implies a tiering convention, but the description never says when this basic variant is preferable over sec_action_radar_evidence.

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, non-destructive and open-world behavior, so the safety profile is covered. The description adds tier/beta context and lists the returned artifacts, but says nothing about rate limiting, authentication expectations, or result caps beyond what annotations provide.

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 fragments with no filler, and the distinguishing content (what the signals carry) follows immediately. Leading with 'FREE beta' is marginally wasteful since it is not decision-relevant for 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?

With no output schema, the description sensibly enumerates the returned fields, which is the right thing to cover. But it omits the basic-vs-evidence tier difference, the meaning/bounds of 'limit', and pagination or result-volume behavior, leaving gaps for a two-parameter retrieval tool.

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%: 'cik' is documented in the schema, but 'limit' (max 500) has no description anywhere, and the description supplies no parameter information at all. With a low coverage ratio the description was expected to compensate, and it does not.

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?

It names a specific resource ('Form-based corporate-action signals') and enumerates the payload it returns (confidence, accession numbers, filing URLs, provenance), so an agent knows what it will get. However it uses no verb and never distinguishes itself from the sibling sec_action_radar_basic, so the tier boundary has to be inferred from the name alone.

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?

There is no statement of when to call this versus sec_action_radar_basic, no prerequisite (e.g. valid CIK format or SEC rate/identity requirements), and no exclusion conditions. 'FREE beta... Intended future paid tier' is licensing information, not usage 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, idempotent, non-destructive behavior, lowering the bar. The description adds genuine context beyond them: 'FREE beta' flags pricing/maturity and 'compact latest observations' discloses the return shape (summarized, most-recent-only). It still omits rate limits, auth requirements, and error 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?

Two short sentences with zero filler and the 'FREE beta' caveat front-loaded. It is efficient, though the extreme brevity leaves gaps that a slightly longer description could close.

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 should carry return-value detail, but 'compact latest observations' is the only hint about what comes back. It also leaves the required 'cik' parameter unexplained and gives no sizing, pagination, or versioning guidance.

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%: 'cik' has a pattern but no description, and 'concept' carries its own schema description. The tool description adds no meaning to either parameter, so it fails to compensate for the undocumented 'cik' field even though it implies a company-scoped search.

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 (Search) and resource (SEC XBRL facts) plus a scope qualifier (latest observations). The word 'compact' implicitly contrasts with the sibling sec_company_fact_search_evidence, but the differentiation is left for the agent to infer rather than stated explicitly.

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?

'FREE beta' signals cost/availability but gives no when-to-use guidance, no prerequisites, and no rule for choosing this basic tool over the adjacent sec_company_fact_search_evidence sibling. The agent must guess at the selection criteria.

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=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false. The description adds beta/pricing context and hints at richer output ('multiple observations and source provenance'), but does not disclose rate limits, auth requirements, or data freshness.

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 short and avoids bloat, but it front-loads a marketing note ('FREE beta') rather than the core function, and the 'Intended future paid tier' sentence does not help an agent invoke the tool.

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 and only a two-parameter search tool, the description should clarify return shape or evidence-tier meaning, but it only gestures at 'multiple observations and source provenance.' It is not complete enough for an agent to know what a call yields.

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%: the concept parameter has a description in the schema, but cik has none. The description does not explain either parameter or add format/meaning beyond the schema, so it fails to compensate for the undocumented cik 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 names the resource (SEC XBRL concept matches) and some output traits, but uses a noun phrase rather than a clear action verb and offers no sibling differentiation from sec_company_fact_search_basic. An agent can infer a search operation from the name, but the description itself is vague about the action.

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 guidance, no alternatives, and no conditions for choosing the evidence tier over the basic tier. The pricing notes ('FREE beta', 'Intended future paid tier') are not usage direction.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful non-annotation context — 'FREE beta' (cost/pricing) and compactness for token budgeting — but says nothing about rate limits, freshness, or the shape/size of what comes back.

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 very short sentences with the pricing note front-loaded, no filler or redundancy. It is tersely efficient, though at the cost of the guidance an agent arguably 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?

No output schema exists, but the tool is a simple two-parameter read whose annotations carry the safety profile. Missing sibling differentiation and the undocumented limit parameter keep it at minimum-viable rather than complete.

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%: cik is documented, but limit (1-500) has no description in either schema or prose. The description adds nothing about parameter meaning, defaults, or how limit interacts with screening, so it fails to compensate for the coverage 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?

States a specific resource (recent SEC filing metadata) and its character (compact, screening-oriented), so an agent knows it is a filing-listing tool. However, it never distinguishes itself from the sibling sec_recent_filings_evidence, leaving the basic/evidence split to be inferred.

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 phrase 'optimized for low-token agent screening' implies when to reach for it (cheap first-pass triage), but there is no explicit when-to-use, no exclusions, and no pointer to the evidence sibling as the follow-up alternative.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context: it is a free beta with larger limits that may become a paid tier. It does not disclose rate limits, pagination, or latency behavior beyond that.

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 fragments, front-loaded with 'FREE beta' and no filler. The pricing/maturity tags are arguably non-operational, but they are cheap and come first.

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?

No output schema exists, and the description compensates by naming the returned fields (accession data, filing URLs, retrieval provenance). Combined with the schema's cik pattern and limit bounds, an agent has enough to invoke it; the only real gap is the absent comparison to the 'basic' sibling.

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%: 'cik' is documented in the schema, 'limit' has bounds but no description. The phrase 'larger limits' hints that limit is the lever for result volume, but no format or default is given. Baseline 3 is appropriate given the schema carries half the load.

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 the resource clearly (recent SEC filings) and enumerates what it returns — accession data, filing URLs, retrieval provenance — plus 'larger limits'. It implicitly separates itself from sec_recent_filings_basic via those extra fields, but never names the sibling, so the distinction requires inference.

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 guidance on when to choose this over sec_recent_filings_basic, despite the 'basic'/'evidence' pairing being the central selection decision. 'FREE beta' and 'Intended future paid tier' describe pricing posture, not usage conditions.

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, so the safety profile is handled. The description adds genuine context beyond the annotations: 'deterministic' (same input yields same signals) and 'FREE beta' (cost/availability status). It does not disclose output shape or limits on text size.

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 compact sentences that front-load price/status and then the core capability. 'FREE beta' is marketing-leaning but does convey actionable availability information; nothing is redundant.

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 single-input screening tool with no output schema, the description is adequate but leaves the return shape undefined — an agent cannot tell whether it gets booleans, matched snippets, or a score per signal category. The basic-vs-evidence distinction against its sibling is also unexplained.

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?

One parameter at 0% schema description coverage, so the schema offers only min/maxLength constraints. The phrase 'in supplied tender text' implies the single 'text' input is the tender document to screen, which adds some meaning, but no format or size expectations are stated.

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 ('screening') and resource ('supplied tender text'), and enumerates the signal categories checked: set-aside, NAICS, PSC, security-clearance, dates. The 'basic' suffix plus the sibling 'tender_preflight_evidence' implies a tier distinction, though the description never explains it.

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 explicit when-to-use or when-not-to-use guidance. The agent must infer from the 'basic' vs 'evidence' naming convention which tool to pick, and nothing states prerequisites or the alternative path.

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, and destructiveHint=false, so the safety profile is covered externally. The description adds status context (free, beta, future paid tier) which is mildly useful, but it discloses nothing about limits, input expectations, or what the 'evidence categories' output actually contains.

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 short sentences, so it is compact, but the second sentence is purely commercial-tier marketing rather than selection-relevant information. It is terse without being informative.

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 explaining returns, yet 'evidence categories and interpretation notes' is left undefined. Combined with the undocumented input parameter, the definition is too thin for an agent to invoke confidently.

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 single 'text' parameter has no schema description (0% coverage) and the description never mentions it at all — it does not say whether text is a tender document, a query, or a URL. With low coverage and no compensating detail, the agent is left guessing what to supply.

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 names a recognizable activity (tender screening) and adds that it returns evidence categories and interpretation notes. However, it never explains what distinguishes it from its obvious sibling tender_preflight_basic, so an agent cannot tell the two apart from the text alone. The purpose is vague rather than specific about scope.

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?

There is no when-to-use guidance, no exclusions, and no named alternative despite the surrounding basic/evidence sibling pattern. 'FREE beta' and 'intended future paid tier' are commercial status statements, not usage instructions.

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 adds two useful behavioral notes (free/beta tier, deliberately compact output), but 'compact' is never explained — the agent cannot tell what is truncated or whether the result is complete.

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 short fragments, front-loaded with the tier caveat and the core purpose — nothing wasted. It is arguably too terse for a tool with an undocumented parameter, but there is 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?

For a one-parameter, no-output-schema tool whose annotations already cover safety, the description is close to adequate: it names the source, the key, and the compact nature of the return. It falls short on award-ID format and on what 'compact' excludes, which are the two things an agent would need to call and interpret it confidently.

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?

With a single required parameter and 0% schema description coverage, the description carries the burden; it does say the tool is keyed by award ID, but gives no format, source, or example of a valid award ID (the schema only enforces 1-200 chars). This is minimal compensation for the coverage 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?

States a specific verb (summarizing), resource (USAspending federal award), and access key (award ID), so the agent knows exactly what it retrieves. It does not distinguish itself from the sibling us_federal_award_evidence, leaving the basic-vs-evidence split to be inferred from the naming convention.

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?

'FREE beta' implies a cost/availability consideration but the description never says when to pick this over us_federal_award_evidence or what prerequisite (a valid award ID) it needs. Usage is only implied by the tool name pattern, not stated.

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 only that the response is 'richer' and avoids 'an unbounded raw passthrough' — a vague, unquantified claim about output size rather than concrete behavior such as rate limits, latency, or beta stability.

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?

It is short and front-loaded with the 'FREE beta' status, so it is not verbose. However, several sentences are marketing framing ('avoiding an unbounded raw passthrough', 'Intended future paid tier') that convey little operational value.

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 should explain what 'evidence' and 'provenance' return, yet it does not. Combined with zero parameter documentation and no sibling differentiation, an agent lacks what it needs to confidently call this tool over us_federal_award_basic.

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 0% and the single parameter award_id is never mentioned in the description, so no format guidance is given (e.g. USAspending award ID vs. internal ID, expected string shape). Only the parameter's self-describing name carries any 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?

The phrase 'Richer USAspending award evidence and provenance' names the resource (USAspending award evidence) but uses no verb describing what the tool actually does, and it never explicitly contrasts itself with the sibling us_federal_award_basic. An agent can infer a tiering from the name pattern but not from the text.

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 says nothing about when to choose this over us_federal_award_basic or the other *_evidence siblings. 'FREE beta' and 'Intended future paid tier' are pricing/commercial notes, not usage guidance, so the agent gets no selection criteria.

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, non-destructive, and open-world behavior, so the safety profile is covered. The description adds cost ('FREE beta') and result-size ('compact') context, but says nothing about auth, rate limits, or result fields.

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 terse fragments that waste no words, though leading with 'FREE beta' rather than the search action is a slightly awkward front-loading choice.

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 two-parameter read-only search with no output schema, the description covers the basic action but omits limit behavior, pagination, and any hint of what 'compact' results contain. Adequate but with clear gaps.

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 0%, so the schema alone leaves both parameters unexplained. The description partially compensates by indicating query accepts names or UEIs and that a result-size cap (limit) exists, but it adds no syntax or format detail for either 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?

States a specific verb (Search) and resource (USAspending recipient names/UEIs) with a scope qualifier (compact results). The 'compact results' phrasing faintly distinguishes it from us_recipient_search_evidence, but the sibling is never named, so an agent must infer the distinction.

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 no when-to-use, when-not, or alternative guidance. It does not point to us_recipient_search_evidence for fuller results, leaving the agent to guess between the two on its own.

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, open-world, non-destructive semantics, so the safety profile is handled. Beyond that the description adds only marketing framing ('FREE beta', 'future paid tier') and the vague 'authoritative API provenance' — it says nothing about latency, rate limits, result completeness guarantees, or how the evidence tier's behavior differs from basic. Annotations do not contradict the description.

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 sentences, front-loaded with the beta status. They are compact, but the content is mostly tier/billing framing rather than tool behavior, so the brevity does not buy useful information density.

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?

No output schema, so the description should at least sketch what is returned (recipient records with provenance fields?). Combined with zero parameter documentation and no sibling differentiation against us_recipient_search_basic, the definition is incomplete for an agent deciding whether and how to call this tool.

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 0%, so the description bears the burden of explaining the query and limit parameters, and it explains neither. It never says what 'query' matches (name, UEI, DUNS, keyword), what the limit cap of 50 means, or that query is required with a 2-100 character range. The only numeric hint is the vague phrase 'larger result set', which is not tied to the limit 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 title and name establish that this is a recipient search tool with an 'evidence' tier, and the description mentions 'Larger recipient result set with authoritative API provenance.' That's a vague characterization of what makes it different from us_recipient_search_basic — it implies scale and provenance but never states the search domain (federal awards/grants recipients) or search behavior (what query matches against). The sibling us_recipient_search_basic is not named or contrasted.

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 or when-not-to-use guidance at all. The description mentions 'Intended future paid tier,' which is pricing metadata, not usage guidance, and actively leaves the agent unclear on whether this tier is appropriate to call now. The obvious alternative (us_recipient_search_basic) is never mentioned.

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