SpendQuery

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

Annotations already cover readOnly/idempotent/non-destructive, so the description earns credit for adding behavioral detail beyond them: default fiscal year is the last complete one, results are ordered largest first, and the three modes behave differently. It doesn't mention pagination or what fields each row carries.

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?

Front-loaded and dense: the resource, the mode dispatch, and the default are covered in a few sentences with no filler. The telegraphic quasi-syntax ('kind: psc ... | naics') is compact but slightly cryptic on first read.

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 still conveys what rows look like (groups, or codes with contract spend, sorted largest first) and what the default period is. An agent can call it correctly and interpret results without opening anything else; only row field details are missing.

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 100%, so every parameter is already documented, which sets the baseline at 3. The description adds genuine value on parameter interaction (group vs query precedence) and gives PSC group examples ('D = IT services', '84 = clothing'), but largely restates the schema's own enum and group semantics.

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 opens with a specific verb and resource ('Browse what the government buys, with contract spend') and immediately scopes it to two code systems via kind. It's clear what the tool returns, though it never names siblings like search_codes or naics_finder to differentiate the browse-vs-search split.

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?

Explicitly maps input combinations to outcomes: no group and no query -> groups, group -> codes in it, query -> name matches. That's actionable routing logic. It lacks any negative guidance (when NOT to use this versus search_codes), which keeps it below a 5.

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 closed-world, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the tool takes no arguments and is the entry point, and the section choices trade breadth ('states' in brief, 'full' as everything) against depth ('state:<CODE>' in full), which hints at payload size. It does not describe response format or potential truncation of 'full'.

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 contents enumeration is front-loaded, then the 'call this first' directive, then the section breakdown — a sensible order for an agent. It is somewhat dense and the section list duplicates the schema's parameter description almost verbatim, which is wasted space, but nothing is irrelevant.

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 burden of telling the agent what comes back, and it does: a catalog of coverage, metrics, dimensions, analyses, planning schema, rules and examples, with granularity controls. Missing are the response format and the practical size of 'full', but for a one-optional-parameter discovery tool this is nearly 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 description coverage is 100% and the single parameter's schema already documents 'Omit for the federal catalog' plus every section value. The description restates this with the same examples ('state:MA'), adding a small amount of reinforcement but no meaning beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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 both the verb (get) and the resource, then enumerates the concrete contents: data coverage, metrics, dimensions, analyses, the QueryPlan JSON schema, planning rules and worked examples. It also distinguishes itself from siblings by positioning itself as the entry point ('Call this first'), which is enough for an agent to tell it apart from run_plan, search_far, etc.

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?

'Call this first (no arguments)' is an explicit sequencing directive that tells the agent exactly when to reach for this tool. It also explains how to choose the section value ('states' in brief vs 'state:<CODE>' in full vs 'full'). It stops short of stating when not to call it (e.g. repeated calls, or that discovery should precede run_plan), so it is not a full 5.

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 closed-world, so the safety profile is covered. In the absence of an output schema, the description carries the return-value burden and does so by listing the payload contents (paragraphs, part/subpart, inbound and outbound references, Federal Register rules). It does not say what happens when a section number is invalid or not found, which is the remaining gap.

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 dense sentence that front-loads the resource and then the payload, followed by a short citation directive. Nothing is wasted, though the opening fragment ('One FAR or DFARS section's full text') reads as a noun phrase rather than a verb-led statement of action.

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 must describe returns, and it does so thoroughly for a read-one-entity tool, plus it supplies the citation format including the as-of date. Missing only error/not-found behavior and any note on size limits for very long sections.

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% and the single 'section' parameter already documents its format with three concrete examples, so the description adds nothing beyond the schema. Baseline 3 applies for a fully documented one-parameter tool.

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 specific resource — 'One FAR or DFARS section's full text' — and enumerates what comes with it (part, subpart, references, Federal Register rules), which clearly separates it from sibling search tools like search_far. It lacks an explicit contrast sentence naming those siblings, keeping it below 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?

Use is implied by 'One ... section' — that is, use this when you already know the section number, and use search_far otherwise — but the description never states this or names the alternative. The only explicit usage instruction is the citation convention ('Cite it as FAR <section> ... with the as-of date'), which is genuinely useful but about output handling rather than tool selection.

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, non-destructive, and closed-world behavior. The description adds useful behavioral context by explaining that the result is a deterministic 'no AI' brief with labelled decision-card lines and confidence-labelled timeline links, though it does not mention auth or rate-limit 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?

The key point is front-loaded: it returns one SAM.gov contract notice. The sentence is dense and uses long parenthetical lists, but the detail is largely justified because there is no output schema and the return shape is non-trivial.

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 must explain what comes back, and it does: decision card contents, timeline elements with confidence labels, and file-version diffs. Combined with the fully documented single parameter and annotations, this is complete enough for an agent 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?

Schema description coverage is 100%, so the schema already documents notice_id format and sources, including the SAM.gov URL pattern and run_plan rows. The description repeats those sources but adds no additional syntax or semantic detail beyond the schema, making the baseline score 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 clearly states it retrieves one SAM.gov contract notice and enumerates the brief contents: decision card, timeline, and file-version changes. It is specific about the resource and verb, but it does not explicitly distinguish itself from sibling search or planning tools such as run_plan.

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 'One SAM.gov contract notice' and by saying notice_id comes from run_plan contract_opportunities rows or a SAM.gov notice URL. However, there is no explicit guidance on when to use this tool versus search tools or run_plan, and no exclusions or prerequisites are 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 read-only, idempotent, closed-world, so the bar is lower; the description still adds real value by disclosing the evidence basis (SAM.gov notice titles, federal contract descriptions) and that each code comes with its SBA size standard. It stops short of saying how many codes are returned or how they are ranked.

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?

One front-loaded sentence with an arrow structure that puts input before output; the parenthetical is dense but every clause carries information. Slightly long for what it says, but 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 no output schema, the description does the necessary work of explaining what comes back: codes plus size standards. Only the result count and ordering are left unspecified, which is a minor gap for a single-parameter lookup 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 100% and the single parameter already documents the plain-language input with two concrete examples. The description's 'work in plain words' phrasing restates the schema without adding format, length, or granularity guidance.

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 transformation: plain-language work description -> NAICS codes, plus the SBA size standard. It implicitly separates itself from browse_codes/search_codes by grounding results in buyer usage, but never names those siblings explicitly, so differentiation is inferred rather than stated.

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 input pattern ('Describe the work in plain words') implies when to reach for this tool, but there is no explicit when-to-use/when-not guidance and no mention of when to prefer search_codes, browse_codes, or size_standard for adjacent needs.

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?

With annotations already covering read-only and idempotent behavior, the description adds substantial return-value context: status values (ok, clarify, unsupported, error), a one-paragraph answer, columns, rows capped at 100, the executed SQL, caveats, and name-resolution details. This is especially valuable because there is no output schema.

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 compact sentences, front-loads the action, and then efficiently enumerates the return contract. Every clause carries useful information.

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 complex nested QueryPlan with no output schema, the description covers the plan source and enumerates the return fields well. It could go further by explaining how to handle clarify or unsupported statuses, but it is sufficiently complete for 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 coverage is 100% and the plan parameter already includes an example and a reference to get_catalog's plan_schema. The description repeats the same reference but adds no additional parameter syntax or constraints beyond the 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?

The description states a specific verb and resource: 'Run a QueryPlan' for a spending query. It also distinguishes the tool from get_catalog by pointing to get_catalog.plan_schema for the plan structure.

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 reference to get_catalog.plan_schema implies that a plan must come from the catalog, but the description does not explicitly say when to use run_plan instead of siblings such as get_catalog, search_far, or browse_codes. Usage is implied rather than spelled out.

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 the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the description is not responsible for basic safety disclosure. It adds useful behavioral context beyond annotations: data provenance from SBA's SBIR.gov records, the award-year counting semantics, and the side effect of open_topics querying SAM.gov and Grants.gov. It does not discuss pagination, rate limits, or freshness beyond the source caveat, but the key operational semantics are present.

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 front-loaded with the resource and scope, and every major clause—returned dimensions, filter list, open_topics behavior, and the run_plan caveat—contributes useful information. It is a dense paragraph rather than a crisply structured list, and the filter enumeration partly duplicates the schema, which keeps it from a 5.

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 must explain return values; it does so comprehensively by naming totals, awards by year and phase, agency breakdowns, top companies, and the fields of latest awards. All eight parameters are accounted for, the open_topics behavior is described, and the counting caveat versus run_plan is included. An agent has enough information to call this tool 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?

Schema description coverage is 100%, so the input schema already documents all eight parameters thoroughly, including examples and enums. The description restates the filter list and examples but does not add syntax or meaning beyond what the schema provides, such as expected formats for combined filters or default behavior. The baseline of 3 is appropriate when the schema carries this much weight.

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: searching SBIR/STTR awards since 1983 and who received them. It enumerates the returned dimensions (totals, awards by year/agency, top companies, latest awards) so the agent knows exactly what this tool produces. It also distinguishes itself from the USAspending-based run_plan tool, making selection between them possible without opening schemas.

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 clearly explains the filters and adds the crucial caveat that SBIR.gov counts awards by award year while run_plan counts money by fiscal year, so the two differ. That gives strong context for when this tool is appropriate versus run_plan. It stops short of explicitly saying when not to use this tool, so it is not a full when/when-not/alternatives statement.

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 safety (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely new behavior: substring, case-insensitive name matching and code-prefix matching. It stops short of disclosing result ordering, whether partial matches are ranked, or what happens on zero matches.

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 lines, front-loaded with the purpose before the kind enumeration and matching rules. The kind list duplicates the enum from the schema, which is minor redundancy but aids at-a-glance scanning.

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 simple read-only lookup with full schema documentation and no output schema, the description covers purpose, entity kinds, and matching semantics well enough to call correctly. It omits what a returned row contains (code plus official name pairing) and any ordering, which is a small gap rather than a blocker.

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 100%, so the baseline is 3, but the description adds meaning beyond the schema by specifying prefix matching for codes and case-insensitive substring matching for names, which the schema only gestures at with 'Words in the name, or the code itself.' It adds nothing about limit, though that is fully documented in the 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 and resource ('look up codes and official names') and enumerates the seven kinds of entities covered, so an agent knows exactly what domain this resolves. It does not distinguish itself from the sibling browse_codes or naics_finder, leaving ambiguity about which to pick for the same kind values.

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 only implied: the matching rules ('names or code prefixes') and the note that 'plans can use either the names or the codes' hint at when this is needed as a resolution step. There is no explicit when-to-use versus browse_codes, and no stated exclusions or prerequisites.

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 and non-destructive, so the safety profile is covered. The description adds genuinely useful behavior: what is returned (section numbers, titles, snippet) and the caveat that eCFR codified text lags the Revolutionary FAR Overhaul class deviations, which affects result trustworthiness.

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?

Dense and front-loaded with the core purpose and matching rule first, then scope and follow-up. The fragment 'straight to it' and the dangling 'reg: FAR | DFARS to limit' read as slightly compressed notes rather than clean prose, which costs a point.

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 description compensates by stating the return shape (section numbers, titles, snippet). With only two parameters, full schema coverage, and annotations covering safety, the only remaining gap is whether results are ranked or paginated.

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 100%, so the baseline is 3, and the description still adds meaning: the query is conjunctive (every word must match, in title or text) and may instead be a section number, and reg limits results to one regulation. This goes beyond the enum and field descriptions.

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 ('Search the FAR and the DFARS') plus the exact matching semantics: all query words in title/text, or a section number. It also names get_far_section as the follow-up, so an agent can distinguish searching from reading without opening other schemas.

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 routes the agent explicitly: search here, then 'read one with get_far_section', and gives an example query ('52.219-14') that shows direct-lookup usage. It lacks explicit when-not-to-use guidance versus siblings like search_codes, but the search-vs-read split is clear.

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 read-only, idempotent, non-destructive, and closed-world behavior, so the description's job is lighter. It adds genuinely useful behavior context: coverage is partial and the agent should say so when a place isn't covered, ordering differs by kind, and each row links to the government's own record via source_url.

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?

Front-loaded with purpose, then the kind definitions, then per-parameter guidance, then the coverage caveat—a logical order. The long parenthetical roster of agencies (LADWP, LAUSD, airports, port, Metro, etc.) is somewhat bloated but does carry real coverage information, so it largely earns its place.

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?

Without an output schema, the description covers what matters: the result rows link to source_url, the reply contains source keys usable in the source filter, and partial coverage should be disclosed to the user. It does not describe limit defaults, but the schema handles that.

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 baseline is 3, and the description exceeds it by clarifying that state applies only to open and planned bids, that source must be one of the keys returned in the reply, and by giving concrete examples of kind semantics and ordering. No syntax details for q beyond title/description matching, which is already in the 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 and resource (search state/county/city bids and contracts) and immediately excludes federal awards, which is the key disambiguation. The enumerated source coverage makes the exact scope of the tool unmistakable and clearly separates it from siblings like sbir_awards or search_recipients.

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?

Explains what each kind value means and when it applies (open = taking responses, planned = forecasts, awarded = recent wins, current = in force), plus which filters are valid for which kinds (state applies to open and planned). It does not explicitly contrast this tool with named sibling tools beyond the federal-awards exclusion, so it falls short of a 5.

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/closed-world, so the bar is lower, yet the description adds substantial non-obvious behavior: result ordering ('largest first'), the data model caveat that a parent's money sits on its units, that a parent UEI's own obligations 'can be small or negative', and that parent_rollup is returned. These are semantics an agent cannot infer from structured fields and would otherwise misread.

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 core purpose and the run_plan alternative are front-loaded, and every sentence carries content. The middle sentence is heavily packed with parentheticals ('parent, listed-company ticker (if matched)... its OWN obligations'), which taxes readability slightly, but nothing is extraneous.

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 must explain returns, and it does: UEI, parent, ticker when matched, own obligations, ordering, and parent_rollup. For a data-model-subtle tool, it supplies exactly the context needed to interpret results 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?

Schema description coverage is 100%, so the schema already documents both 'query' and 'limit' fully, including the UEI example. The description restates the name/UEI dual-mode lookup but adds no syntax or constraint beyond the schema, so baseline 3 applies. Notably, 'limit' is not mentioned in the description at all.

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 first sentence names a specific verb and resource ('Find award recipients') and enumerates entity types (companies, universities, governments) plus the lookup keys (name or UEI). This is clearly distinguishable from siblings like run_plan, search_codes, or naics_finder.

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 routes the agent: 'for a company's total use run_plan with a company filter (name or ticker).' That is a named alternative with the exact condition that selects it, which is exactly what usage guidance should do.

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/closed-world, so the safety profile is covered. The description adds real value beyond that: it cites the authoritative source (13 CFR 121.201 eCFR table) and enumerates what comes back — thresholds in receipts or employees, exceptions, footnotes, and the programs that rely on them.

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?

One sentence, front-loaded with the regulatory source, then a compact input-to-output mapping. The telegraphic arrow notation is efficient but slightly terse, reading more like a fragment than guidance.

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 single parameter and no output schema, the description carries the return-value burden and does so — thresholds, exceptions, footnotes, programs. The only unaddressed case is ambiguity resolution (e.g., whether industry words can return multiple matches), which is a minor gap.

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 100% and the single `query` parameter already documents all three accepted forms with examples. The description restates the same input forms (NAICS code, prefix, industry words) and adds only the output units, so it does not meaningfully exceed the schema's own documentation.

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 specific resource (SBA small business size standards, 13 CFR 121.201) and states the exact outputs: a receipts ($ millions) or employee threshold plus exceptions, footnotes and the programs that use them. It does not, however, distinguish itself from close siblings like naics_finder or browse_codes, so an agent must infer the split from the domain framing 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 explicit statement of when to call this versus naics_finder/search_codes, and no prerequisites or exclusions. The intended use (look up a size threshold for a code or industry) is only implied by the input formats listed.

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/closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: it constrains results to the last complete year's obligations, reports a share per vehicle, and explicitly notes that reservation/eligibility is inferred from the vehicle's name — an important caveat about how the data is derived.

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 a single sentence with no filler, but the nested parentheticals ("(and an optional agency)", "(read from its name)") and a list of vehicle types make it hard to parse on first read. Content is front-loaded reasonably but the syntax is denser than necessary.

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 read-only, closed-world lookup with no output schema, the description covers the important things an agent needs: what entities come back (vehicles), what the numbers mean (share of last complete year's money), and how eligibility is determined. Nothing essential for correct invocation appears missing.

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%, with both parameters documented including the 6-digit NAICS format and the agency name-or-code convention. The description only restates that naics is 6-digit and agency is optional, adding essentially no semantics beyond the schema, so the baseline 3 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 names a specific resource domain — shared contract vehicles (GWACs, multiple-award IDIQs, GSA Schedule, BPAs) scored against NAICS-coded contract money — which is clearly distinct from siblings like get_catalog, browse_codes, or search_recipients. It reads as a dense fragment rather than a verb+object sentence, but an agent can still tell what it returns.

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 only implied through the input condition: you need 6-digit NAICS codes, optionally narrowed by agency. There is no statement of when to prefer this over get_catalog or browse_codes, and no exclusions or prerequisites (e.g. what happens with non-6-digit codes, or coverage limits of the underlying data).

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