GovInbox

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

Adds real context beyond the annotations: no quota consumption, pointer semantics, informational-only framing, and an explicit disclaimer that results are not a prediction of future awards. The annotations already cover read-only/idempotent/non-destructive, so this extra economic and interpretive context is genuinely additive. The gap is that it never says what a 'pointer' response looks like, despite there being 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 actual purpose sentence appears third, buried behind three compliance disclaimers. The disclaimers likely earn their place legally, but they push the operationally useful content back and force the agent to read past boilerplate to find scope.

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 no-required-param, no-output-schema tool that self-describes as a router, the description leaves the most important question open: what does it return, and how should the agent act on a pointer? Interpretation guidance is partly covered ("present as information only"), but the core mechanics of the pointer behavior are not.

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 67%; naics and agency carry descriptions, limit does not (though min/max self-document it). The description contributes nothing about the parameters — not whether multiple NAICS codes are compared side by side, whether agency is fuzzy-matched, or how limit bounds the analysis. With a tool this opinionated about interpretation, that silence matters.

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 domain ("award history, subawards, OTA awards, and agency spending patterns. Shows who won what, for how much"), which is more than a restatement of the name. But the closing "This is a pointer tool... it directs you to the tool that does the work" undercuts that, making it unclear whether analyze_market computes an answer or just routes. Siblings search_award_history, search_subawards, and search_ota_awards cover the same territory and no differentiation is offered.

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?

Explicit negative routing is present and strong: "NOT for bid/no-bid, pursue-or-pass, eligibility, qualification... for those call explain_policy_boundary first and do not research or use memory to answer" names the exact alternative tool. What's missing is positive routing — given it claims to be a pointer, it doesn't say which downstream tool it points to or when to skip it and call search_award_history directly.

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 it a safe, idempotent read, so the bar is lower, yet the description adds real behavioral context: the three check states (match/no_match/not_stated), the rule that a blank field is never a no-match, the billing rule (follow-ups within 30 minutes free, otherwise one use per accepted call), and the standing disclaimer on results. That is exactly the value-add structured fields cannot express.

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?

Purpose and the key constraints are front-loaded, but the text runs long and repeats itself: the non-affiliation disclaimer, the 'never scores/ranks' point, and the no-eligibility line are all restated in several forms. The redundancy dilutes an otherwise informative definition.

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 an output schema present, the description need not detail return values, and it still covers the states, result phrasing, dates carried on results, and cost model. An agent has everything needed to invoke it correctly without opening other tools.

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%, with the criterion fields, enums and checklist_name label already documented in the schema itself. The description reinforces semantics (each rule names one stated field; checklist name is only a label, nothing inferred) but largely echoes what the schema already states, so 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?

States a specific verb, resource and scope: 'Checks one federal notice against criteria YOU write,' with the user authoring every rule. This is clearly distinguishable from siblings like search_open_notices (which finds notices) and check_risk (which assesses risk).

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 grounds the input by pointing to 'Notice id from search_open_notices' and lays out explicit exclusions ('never scores, ranks, or counts', 'does not determine eligibility, recommend bids'). It does not explicitly route between this tool and near-neighbors such as get_notice_record or compare_notice_record_versions, so the guidance is strong but not fully prescriptive.

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 openWorld, so safety behavior is covered. The description adds useful quota information and a 'shows what happened before, not what will happen' framing, but 'directs you to the tool that does the work' is incomplete because the target tool is never named. This is not an annotation contradiction, but it is ambiguous.

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 opens with two sentences of legal disclaimer rather than the tool's function, then spends multiple sentences on scope exclusions. The core action is never stated crisply, so the structure is not front-loaded for an agent deciding whether to invoke it.

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 the description never says what a successful check_risk result contains or which tool it points to. For a routing tool with zero required parameters, the destination tool and return shape are essential and 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%, and the schema already documents keywords for cancelled records and notice_id for protest history. The description only loosely maps those domains to the parameters and adds no syntax or selection guidance beyond what the schema provides.

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 risk-signal categories (protest history, cancellation records, opportunity scoring), but it never states whether check_risk returns those records or merely routes elsewhere. The 'pointer tool' claim muddies the verb, and it does not distinguish itself from sibling tools like get_protest_history or search_cancelled_contracts.

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 excludes bid/no-bid, eligibility, certification, and related questions, and names explain_policy_boundary as the alternative for those cases. However, it gives no positive trigger for using check_risk over get_protest_history or search_cancelled_contracts, so the core routing decision is left to inference.

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?

Goes well beyond the annotations: it discloses that a new private receipt is created with a UTC expiry in expires_at, that the receipt is caller-scoped and expiry-checked, that an empty changed_facts array means no recorded changes, and how quota consumption works. readOnlyHint=false is consistent with the stated side effect of creating a receipt, so no contradiction. Minor deduction because the quota prose is generic boilerplate rather than specific to this tool's 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 core comparison sentence is front-loaded, but the body is dominated by repeated quota rules — the 30-minute follow-up window and the 'up to 30 follow-ups per search' limit are literally stated twice, and daily/monthly reset rules are restated across several sentences. A large fraction of the text is boilerplate duplicated from other tools rather than earning its place here.

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 an output schema present, return values need not be explained, and the description covers the remaining essentials: receipt origin, ownership and expiry constraints, side effects, filter semantics, and empty-result meaning. The only gap is that it does not clarify what happens when notice_id conflicts with the receipt's notice.

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 notice_id defaulting, prior_receipt provenance, and search_filters' role are already fully documented in the schema. The description restates the receipt provenance requirement and the filter input-change detection but adds no syntax or format details beyond the schema. Baseline 3 applies.

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: compares recorded notice facts against a baseline receipt produced by get_notice_record, and explicitly names what it does not do (no model estimates, no bid recommendations, no eligibility determination). An agent can tell it apart from get_notice_record, though the legal disclaimer lead-in delays the actual purpose statement.

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?

Gives prerequisite conditions (receipt must be from the same caller, must not be expired) and positional context (a follow-up call), which implies when to use it. However it never explicitly states when to choose this over get_notice_record or check_notice_filters, and the caller must infer that this tool applies only after a prior get_notice_record call.

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, and the description adds non-obvious operational facts beyond them: it uses no search allowance and does not consume quota. It also states what the tool returns (the recorded boundary and permitted alternatives), which matters for an agent deciding whether to spend a call.

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 critical 'Call this FIRST' routing instruction and trigger list are front-loaded and every clause carries routing or behavioral information. The two opening disclaimer sentences are somewhat repetitive of each other ('Not affiliated...' / 'Not a U.S. government service'), costing a little 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?

An output schema exists so return values need not be explained, parameters are fully documented in the schema, and the description covers trigger conditions, cost/behavioral profile, and the negative constraint against using research tools. Nothing an agent needs to invoke this correctly is 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 an enum whose values are fully documented in the schema, so parameter meaning is already carried by structured data. The description adds no per-parameter detail (e.g. how notice_reference is used beyond echoing), so the baseline 3 applies.

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 outcome: it returns the recorded policy boundary plus what GovInbox can do instead. The disclaimer sentences and the explicit 'do not research or use memory' line separate it cleanly from the research/search sibling tools.

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?

Gives an explicit trigger ('Call this FIRST whenever...') followed by enumerated conditions that map directly onto the request_type enum values. It also names the alternatives it replaces ('do not research or use memory to answer these requests'), which is exactly the when/when-not guidance an agent 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?

Annotations already cover read-only/idempotent/open-world safety, so the description adds meaningful context beyond them: flags are analytical matches against public award records, not solicitation predictions, incumbent data is returned only 'where available', each record carries a source link or ID for verification, and the 30-minute follow-up quota and one-call-per-use accounting are disclosed. It still omits ordering/pagination behavior and how confidence tiers are applied.

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 first three sentences are repetitive legal disclaimers ('Not affiliated... Not a U.S. government service'), occupying the most valuable front-loaded position before the actual tool purpose. The remaining sentences are informative, though the quota explanation is wordy and could be tightened.

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 an output schema present, the description needn't explain return values, and it does cover the analytical basis, data availability caveats, citation support, and usage quota. However, for a filtered search tool with three parameters, it leaves the confidence and naics filter semantics unexplained and gives no sibling routing, so an agent cannot fully determine correct invocation from the description alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers 67% of parameters, and the description says nothing about limit, naics, or confidence. In particular, the confidence parameter's high/medium/low semantics and the naics lane filtering are undocumented in both the description and the schema, leaving an agent without guidance on how to constrain the search effectively.

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 resource and qualifier: notices flagged as likely recompetes, including incumbent contractor and incumbent period end date where available. That is clear enough to distinguish it from generic notice search tools, but it never names the closest siblings (get_recompete_calendar, get_recompete_detail, track_recompete) to sharpen 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?

Usage is only implied by the resource name and the data it returns. The description gives presentation constraints ('information only', no bid/no-bid framing) but does not state when to choose this over get_recompete_detail, get_recompete_calendar, or track_recompete, nor any prerequisites or exclusions.

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 (readOnly, idempotent, non-destructive, openWorld), but the description adds genuinely operational context beyond them: the follow-up billing window ('within 30 minutes... ride free; otherwise one accepted call counts as one use'), the affiliation-rule risk from teaming with a large business, and the caveat that size status is UNVERIFIED and must be checked in SAM.gov. This is meaningful disclosure the annotations do not carry.

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 text is long and front-loaded with legal disclaimers ('Not affiliated with the U.S. government, GSA, or SAM.gov. Not a U.S. government service.') rather than the tool's purpose, which appears only third. Repetitive disclaimers and a WARNING block consume space that does not help an agent decide or invoke correctly.

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 2-parameter tool with no output schema, the description conveys what kind of records come back (firms with teaming history) and the domain caveats, but it does not describe the return structure or the meaning of 'limit' beyond the schema. Adequate for invocation, incomplete on results.

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%: 'naics' is documented in the schema ('NAICS code for the trade lane') and the description reinforces the 'trade lane' concept, but neither the schema nor the description explains 'limit' (default 10, max 25). The description adds only marginal meaning over the structured fields, 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 sentence 'Find firms with a track record of teaming in a trade lane, based on historical subaward and prime-award activity' gives a specific verb+resource and the data basis. However, it is buried behind three sentences of disclaimers, and it does not distinguish this tool from the similarly named sibling 'find_teaming_partners', leaving ambiguity an agent cannot resolve from the description 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?

The description tells the agent how to present results ('information only', 'not recommendations') but never says when to use this tool versus alternatives such as find_teaming_partners or research. There is no when-to-use or when-not-to-use guidance for tool selection, only framing rules for the output.

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 establish read-only, idempotent, non-destructive behavior, and the description still adds substantial non-obvious context: results are historical facts from reported subaward filings, inclusion does not imply a prime is seeking partners, size status is UNVERIFIED and must be checked in SAM.gov, exclusion screening is not established, and every record carries a source link for citation. It also discloses the billing/rate-limit model (free follow-ups within 30 minutes, otherwise one call per use).

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 sentence arrives after two near-duplicate disclaimers ('Not affiliated with the U.S. government, GSA, or SAM.gov. Not a U.S. government service.'), which is wasted front-load. The remainder is dense but mostly earns its place: affiliation-rule warning, unverified size status, and the rate-limit sentence.

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 an output schema present and annotations covering safety, the description needs only to frame interpretation, scope, and limits, which it does thoroughly. The one gap versus sibling differentiation (find_partners) is a routing concern rather than a completeness-of-calling concern, keeping it just under a 5.

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 80%, so the schema already documents naics, state, agency, and certifications well, and the description adds only the framing that rankings are on subcontracting in 'these lanes.' It adds nothing on limit, on the state/place-of-performance semantics, or on how certification filters interact with the ranking, so it does not exceed the baseline for a high-coverage 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: primes with a recorded subcontracting track record in a NAICS lane, ranked by small-business subaward history. That is far more precise than the title. It does not, however, distinguish itself from the overlapping sibling find_partners, so an agent cannot tell which of the two to call from this text 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?

It gives a clear usage context ('For a small business looking for teaming conversations: which primes have actually used subs in your lane') and firm interpretation limits ('do not frame results as a bid/no-bid recommendation, eligibility determination, or partnership recommendation'). But it never names an alternative tool or says when not to call this in favor of find_partners, which is the obvious sibling in this space.

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, open-world, and non-destructive behavior. The description adds important behavior beyond annotations: it is a pointer tool, does not consume quota, directs the caller to the tool that does the work, presents information only, and returns one or two lines per item for scanning.

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 contains useful constraints, but the opening disclaimers are repetitive and push the actual purpose behind them. The content is reasonably organized after that, yet it could be tighter and more front-loaded around what the tool returns.

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 pointer tool with one optional parameter and no output schema, the description explains the content categories, scan-friendly output format, quota behavior, and policy-boundary exclusion. An agent has enough context 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?

The schema has 100% description coverage for the single optional date parameter, including YYYY-MM-DD format and defaulting to today. The description adds no additional parameter guidance, so the schema already carries the parameter 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 clearly says this returns the GovInbox daily brief and lists its contents: new opportunities, expiring notices, awards, grants, and regulatory changes. It does not explicitly distinguish this from siblings such as show_govinbox or the search_* tools, except for the policy-boundary exclusion, so it is clear but not fully differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a strong explicit when-not rule for bid/no-bid, eligibility, qualification, certification, and related questions, and routes those to explain_policy_boundary. It also signals the daily-scan use case, but does not explicitly compare this tool with other daily overview or inbox-related 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?

Goes well beyond the annotations (which only cover safe-read/idempotent): it discloses that content is a stored excerpt rather than live text, that every response carries an eCFR version date and verification link, that length limits and content guards can truncate or withhold text with `text_delivery` explaining it, and that follow-up calls within 30 minutes are free while others consume a use. These are exactly the operational facts an agent needs and none of them are in structured 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?

It opens with two defensive disclaimer sentences before saying what the tool does, and it repeats the source-link point twice ('Every response carries… a clickable link' and 'Every record carries a direct source link…'). The usage/rate-limit and legal-disclaimer material is not clearly separated from the functional description, so the agent must parse a legal notice to find the core behavior.

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 an output schema present and a single well-documented parameter, the description covers the remaining gaps well (staleness, truncation via `text_delivery`, citation links, quota). The one missing piece is the not-found / invalid-number case, which matters for a lookup-by-ID 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 schema already documents `clause_number` with the same example format ('52.212-4'). The description adds no syntax, normalization, or failure semantics (e.g. what happens for a non-existent or Section-vs-clause number) beyond the schema, so the baseline of 3 applies.

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 opening substantive clause states a specific resource and retrieval mode: 'Stored excerpt of a Federal Acquisition Regulation section by number (e.g. 52.212-4, 52.219-8), from the eCFR, Title 48.' It is distinguishable from siblings (no other tool looks up FAR text), but the statement of purpose is preceded by two boilerplate disclaimer sentences, which dilutes front-loading.

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 agent infers it should call this when it has a FAR clause number in hand. There is no explicit 'use this when… / do not use for…' guidance and no pointer to an alternative tool for statutes, agency supplements, or free-text regulation 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/non-destructive/openWorld, so the safety profile is covered, but the description adds genuinely new behavioral context: every record carries a source link or source name plus record ID for verification, plus the framing constraint that results must not be presented as an eligibility determination. It also discloses call accounting (one accepted call = one use, free follow-ups after a search), which annotations cannot express.

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 leading sentences are legal/attribution boilerplate ('Not affiliated with the U.S. government, GSA, or SAM.gov. Not a U.S. government service.'), pushing the actual statement of purpose into the fourth sentence. The remaining sentences are dense and useful, but the definition is not front-loaded on what the tool does.

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?

An output schema exists and the input schema fully documents the sole parameter, so the description needn't explain return shapes; it appropriately focuses on verification and citation behavior and use accounting. What's missing is only explicit sibling routing, which is a modest gap for a single-param read 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 100% for the single required parameter, so the schema already explains that opportunity_number comes from a search result. The description adds no additional format, example, or constraint information beyond that, making baseline 3 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 (one grant opportunity) and enumerates the record fields returned: eligibility applicant types, funding categories, award range, dates, summary. Sibling differentiation is only implicit (it's the record fetch behind search_grants_gov/search_open_grants), and it never distinguishes itself from get_record or get_notice_record by name.

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 context is implied rather than stated: the parameter is described as 'Opportunity number from a search result' and the billing note about follow-ups within 30 minutes after a search makes clear this tool is called after a search. However, there is no explicit guidance on when to use this versus the other record-fetching siblings, and no stated preconditions or exclusions.

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?

Beyond the readOnly/idempotent annotations, it discloses a great deal: receipt signing, statelessness and cryptographic verification, 7-day expiry with expires_at, a 30-minute free follow-up window, quota tiers (3/day, 10/month anonymous; 20/month on free account), UTC reset times, and which calls are charged vs not. The 'Creates a receipt' language is reconciled by the explicit no-server-side-storage statement, so it does not truly contradict readOnlyHint.

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 very long and repetitive: the 30-minute follow-up window and the 'one accepted search counts as one use' rule are each stated more than once, and quota resets are recapped twice. It is not front-loaded on purpose; it opens with disclaimers rather than the tool's function. Much of the rate-limit prose could be consolidated or pushed to a dedicated policy field.

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?

An output schema exists, so return values need not be explained, and the safety annotations cover the read-only profile. The description is thorough about constraints and contents, leaving only minor ambiguity about the brief's structure. It is complete enough to invoke 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 coverage is 100%, so baseline is 3. The description adds genuine meaning about search_filters: it is used for 'comparison input-change detection' and 'does not change the brief's content,' which tells the agent something the schema does not. Slightly above baseline for that extra semantic layer.

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 does state a specific verb+resource: 'Returns a source-based brief for a notice ID,' and lists the brief's contents (recorded constraints, deadline status, competition method, source info, verification-needed facts). It also distinguishes itself from explain_policy_boundary. However, the actual purpose is buried behind four front-loaded legal disclaimers, so the reader must dig for 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?

Explicit when-not guidance: 'NOT for bid/no-bid, pursue-or-pass, eligibility... for those call explain_policy_boundary first.' It names the alternative tool and the exact conditions that select it, plus a prohibition on using memory to answer. This is textbook 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 declare read-only/idempotent, and the description adds substantial context beyond them: the full risk-level taxonomy (HIGH/MEDIUM/LOW/UNKNOWN/CLEAR) with its 120-day window, corpus boundaries, data gaps, and the 30-minute follow-up billing rule. This is exactly the kind of behavioral detail annotations cannot carry.

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 risk-level legend and corpus limitations earn their place and the purpose is front-loaded, but the opening disclaimer is redundant ('Not affiliated with the U.S. government, GSA, or SAM.gov. Not a U.S. government service.'), and the FY2025 statistics plus public-domain discussion are tangential to invoking the tool correctly.

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?

An output schema exists so return shape is covered, and the description still supplies the interpretive key for the risk classification that the schema alone would not convey. Combined with corpus scoping and verification advice, nothing needed to call and interpret it is 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?

Only one parameter and schema coverage is 100%, with an example format already in the schema ('W519TC-23-R-0111'). The description adds no further guidance on solicitation-number formatting or normalization, so baseline 3 applies.

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 ('GAO bid protest history for a federal solicitation number') and immediately delimits it: 'This corpus holds GAO decisions only', excluding agency-level protests and Court of Federal Claims dockets. An agent can distinguish this from siblings like check_risk or get_far_clause without 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?

Explicitly frames when-not-to-rely: pending protests aren't covered, dismissals are mostly unpublished, and the agent is told to 'verify status against the GAO bid protest docket before acting.' It gives a clear context of use but never names a sibling alternative, so it stops short of full when/when-not/alternatives.

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/idempotent/open-world safety, the description still adds substantial behavioral context: dates are ESTIMATES that shift with modifications, certain paths (AbilityOne, 8(a) sole-source, schedule orders) never surface as SAM notices, GAO HIGH means a sustained protest within 120 days, and billing semantics ('follow-ups within 30 minutes ride free, one accepted call counts as one use regardless of record count'). It also commits to a verifiable source link per record — all beyond what structured fields declare.

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 dense paragraph whose first two sentences are legal disclaimers ('Not affiliated with the U.S. government...') rather than purpose, so the useful content is not front-loaded. The billing and presentation clauses are necessary but could be tightened; still, nearly every sentence carries information once past the disclaimer.

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?

An output schema exists, so return values needn't be described, yet the description still explains the ranked fields and their interpretation. Caveats on estimate accuracy, non-convertible paths, ranking meaning, and citation requirements make it largely self-sufficient; the only real gap is guidance on the filters and on choosing this tool over its recompete siblings.

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 83%, so the schema already documents naics, agency, days_out, set_aside, and bridge_only, putting this at the baseline. The description itself never mentions any filter (NAICS, agency, days_out window, bridge_only) or the limit cap of 50, so it adds no semantics beyond the schema and an agent could miss that filtering exists 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 description states the resource precisely: contracts whose periods of performance end soon, ranked for business development, with an enumerated field list (incumbent, value, end date, days to expiry, set-aside, bridge flag, SAM follow-on, GAO protest risk). It is clear what the tool returns, but it never distinguishes itself from close siblings like find_likely_recompetes, get_recompete_detail, track_recompete, or list_awards_by_period_end, so an agent must infer which ranked-recompete surface to pick.

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 by phrases like 'ranked for business development' and the presentation rules ('Present as information only; do not frame results as a bid/no-bid recommendation'). There is no explicit when-to-use or when-not-to-use guidance and no named alternative among the many overlapping recompete 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 readOnly/idempotent/non-destructive, yet the description adds real context beyond them: per-call metering ('one accepted call counts as one use'), a 30-minute free follow-up window capped at 30 per search, and provenance via direct source links. It stops short of stating result volume/ranking criteria, so not a 5.

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 legal disclaimer boilerplate ('Not affiliated with the U.S. government...') occupies the opening before the actual purpose, so the description is not front-loaded on what the tool does. The remainder is dense but each sentence carries billing, caveat, or citation 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?

With an output schema present, return values need not be explained, and the description covers the analytical caveat (matches, not confirmed incumbents), metering, and citation guidance. It omits ranking criteria and behavior on a non-recompete notice, which are minor residual 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?

Single required parameter with 100% schema description coverage ('Notice id from a search result'), so the schema already carries the meaning. The description only implies the same constraint ('for one notice') without adding format or retrieval guidance beyond it.

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+resource: 'Ranked candidate incumbent awards for one notice,' sourced from GovInbox recompete analysis of public award records. This clearly separates it from search-oriented siblings (find_likely_recompetes, list_awards_by_period_end) though no sibling is named 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?

Implies the workflow — it is a follow-up detail call for a notice ('Follow-ups within 30 minutes after a search ride free'), suggesting it be used after a search. But there is no explicit when-to-use/when-not or named alternative (e.g. vs. find_likely_recompetes for discovery), leaving selection to inference.

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?

Beyond the readOnly/idempotent annotations, it discloses two things annotations cannot: an auth requirement ('Grants require the full account connection') and a usage/quota model ('follow-ups within 30 minutes... ride free (up to 30 per search); otherwise one accepted call counts as one use'). It also points to record_delivery for output limits and omitted upstream fields, and sets a framing expectation ('Present as information only').

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 tool's actual function is buried in the third sentence behind two sentences of legal disclaimer and one of policy routing, so the definition is not front-loaded. The remaining content is dense but each clause does work; the problem is ordering and density rather than padding.

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 tool with no output schema, it covers auth, quota, output-limit pointer, and liability framing. The one material omission is disambiguation from get_notice_record and get_grant_record, which an agent needs in order to route 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 coverage is 100%, so the schema already carries both parameters, including the rule that record_type is required when a contract and grant share an ID; the description merely restates that. The phrase 'by source ID' adds only marginal meaning about notice_id beyond the schema's 'Contract notice ID or grant opportunity number.'

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 operative sentence 'Get bounded typed details of a contract notice or grant by source ID' is a specific verb plus resource and scope. However, it never distinguishes itself from the closely related siblings get_notice_record and get_grant_record, which an agent will see in the same list; 'Specify record_type when IDs overlap' addresses ID collisions, not tool choice.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit when-not and a named alternative: 'NOT for bid/no-bid, pursue-or-pass, eligibility... for those call explain_policy_boundary first.' It also states a prerequisite ('Grants require the full account connection') and a selection rule for record_type. The gap is that it never says when to prefer this tool over get_notice_record or get_grant_record.

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 open-world behavior, yet the description adds real operational detail: dates are source-reported facts that options or modifications can change, empty results still consume a search, retries and additional pages each count as new searches, and follow-ups within 30 minutes ride free up to 30 per search. That is meaningful billing and rate-limit context an agent cannot infer from annotations. The main weakness is heavy duplication of the same quota rules, which dilutes rather than contradicts the disclosure.

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 is preceded by two legal disclaimers, so the first impression is boilerplate rather than function. The quota material is stated at least twice — 'one accepted call counts as one use, regardless of the number of records returned' and the 30-minute free follow-up rule both appear in near-identical form — while the required NAICS parameter is never mentioned at all. Size is dominated by repetition rather than 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?

An output schema exists, so return values need not be described, and the description does note that every record carries a source link or record ID for verification. However, for a six-parameter tool whose sole required argument is a NAICS code list, the description never mentions that filter, leaving the agent to infer the primary scoping mechanism from the schema alone. It is adequate but leaves a real gap in how to invoke the 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 coverage is 67%, with the schema itself documenting the NAICS pattern, the geography enum, the certification codes, and the cursor's origin, so the baseline is 3. The description refers to a 'requested lookahead window,' loosely mapping to lookahead_months, but never explains that NAICS codes are the required filter or what changing the lookahead range or limit does to results. It therefore adds little beyond the structured 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 gives a specific verb and resource: lists public award records whose recorded period-of-performance end dates fall inside the requested lookahead window. It also draws a useful boundary against solicitations, distinguishing it from search_open_notices. It does not, however, distinguish itself from the thematically closest siblings like find_likely_recompetes, get_recompete_calendar, or search_award_history.

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 phrases like 'requested lookahead window' and 'not open solicitations,' which suggest when the tool applies. There is no explicit statement of when to pick this over find_likely_recompetes or get_recompete_calendar, and no stated prerequisite beyond 'with a connected account' in the quota text. The negative statements ('does not recommend bids, determine eligibility, or suggest partners') constrain scope but do not route the agent to an 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?

Adds substantial context beyond annotations: amounts are prime-reported subcontract values, not cash paid or obligations; reporting may be incomplete or duplicated; missing results do not prove absence of a relationship. It also discloses quota mechanics and that pagination is unsupported.

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 purpose is front-loaded, but the description is dominated by repeated rate-limit and quota text that restates the same rules multiple times. Much of this boilerplate does not earn 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?

For a complex, quota-limited data tool, it thoroughly covers data provenance, limitations, and usage constraints, and an output schema exists for return values. The main gap is lack of explicit sibling differentiation for search_subawards.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers most parameters with descriptions, including NAICS, agency, geography, and certifications. The description only mentions 'limit rows' and adds no filter semantics beyond what the schema already provides, so 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?

States a specific verb and resource: returns reported first-tier subcontract award rows from stored USAspending subaward data. It also clarifies that only reported relationships are returned. However, it does not distinguish this from the sibling search_subawards tool.

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 caveats such as no pagination and no inferred relationships, but does not explicitly say when to use this tool instead of search_subawards or other siblings. The reader must infer the use case from the data source and filters.

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?

Substantially exceeds the annotations: it discloses write-access requirements, that standard dynamically registered OAuth clients are read-only, that approved write clients still need explicit user consent, and precise metering behavior (free follow-ups within 30 minutes, up to 30 per search, otherwise one accepted call = one use). None of that is inferable from readOnlyHint=false / openWorldHint=true.

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?

Six sentences, each carrying distinct information about purpose, effect, permissions, and quota. The three leading legal disclaimers consume the front-loaded position with compliance boilerplate rather than the tool's function, which slightly weakens the opening.

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 an 8-parameter mutation tool with no output schema, the description covers permissions, consent, and cost — the parts an agent cannot get elsewhere. Listing/pagination behavior and the remove_legacy path are left entirely to schema field descriptions, which is acceptable given 88% coverage.

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 88%, so action enumerations, reason values, notice_id, cursor, and legacy_key are already documented in the schema. The description adds only conceptual context (watch vs. pass semantics) and no parameter-level guidance of its own. Baseline 3 applies.

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+resource pairing ("Watch or pass on a contract or grant opportunity") and explains what each outcome produces (saved list vs. recorded reason). It clearly is not a search/retrieval tool like search_open_notices or get_record. It never mentions the list/unwatch/unpass/remove_legacy actions that the schema exposes, so the stated scope is narrower than the tool's actual surface.

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?

Gives a real decision rule: watch saves to your list, pass records why so patterns emerge over time. The 30-minute free-follow-up rule implicitly steers the agent to call this soon after a search. No explicit exclusion or named alternative sibling, but the usage context 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 readOnly, openWorld, idempotent, and non-destructive behavior. The description adds meaningful context beyond that: it warns the DOE source is 'a partial stored source, not a live or complete eXCHANGE search,' states that no company eligibility is assessed, and explains quota behavior ('One accepted DOE search counts as one use' vs. other sources without a primary quota charge). These are useful operational details the annotations do not 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?

The description is long and front-loads two nearly redundant disclaimers ('Not affiliated with the U.S. government, GSA, or SAM.gov. Not a U.S. government service.'), delaying the actual purpose. The remaining content is useful, but the opening could be trimmed and the operational purpose placed 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?

Given a read-only, open-world search tool with an output schema, the description covers the critical non-obvious behaviors: policy boundaries, source-specific behavior, quota implications, partial coverage, and alternatives. The output schema handles return-value details. Minor gaps remain around exact result shape, but the definition is largely complete for safe invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds semantic meaning for the 'source' parameter: DOE eXCHANGE executes a stored lab-call search, while other named sources return only source pointers and coverage metadata without a search or quota charge. That clarifies the consequence of the parameter choice beyond what the schema text alone states.

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 eventually states that for source='DOE eXCHANGE' it searches recorded DOE laboratory-call documents, but the first three sentences are disclaimers and exclusions rather than a clear verb+resource statement. The tool name 'research' is generic, and the actual purpose is conditional on a parameter value, so an agent must read several sentences before learning what it does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says when NOT to use the tool (bid/no-bid, eligibility, certification, etc.) and directs the agent to call explain_policy_boundary first in those cases. It also names alternatives for other sources: 'For FAR, Federal Register, Grants.gov and MCC, use the named source tools.' This is exactly the when/when-not/alternative guidance an agent 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?

Beyond the annotations (readOnly/idempotent/non-destructive/openWorld), it discloses several things the annotations cannot: metadata-only results with documents living on Amtrak's portal, daily refresh cadence, ~1 week listing rotation, usage metering ('one search counts as one use'), and that every record carries a source link or ID for citation. It also explicitly disclaims government affiliation, which is meaningful context for a procurement feed.

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?

Most sentences carry real information, but it opens with two near-duplicate legal disclaimers ('Not affiliated with the U.S. government, GSA, or SAM.gov. Not a U.S. government service.') that delay the actual purpose statement. The core scope sentence should have been front-loaded ahead of the boilerplate.

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?

An output schema exists, so return-value shape needn't be explained; the description instead covers the things structured fields can't — coverage gap vs. SAM.gov, data freshness, metadata-only limitation, and citation via source link. The only real omission is any guidance on the limit parameter and result-set size.

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 67% and both documented parameters (query, category) already explain their own semantics, including the CN/NC/ES category mapping. The description's 'filter by keyword or category' adds no syntax, format, or interaction detail beyond the schema, and the undocumented limit parameter (default 20, max 50) is not addressed 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 description names a specific resource (Amtrak's public procurement portal listings for construction, non-construction services, and equipment sales) and explicitly delimits scope: records 'that do not appear on SAM.gov.' The search verb is implicit rather than stated, but an agent can distinguish this from the SAM.gov-oriented siblings (search_opportunities, search_open_notices) from the text 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?

It gives clear selection context: this feed covers Amtrak-only solicitations absent from SAM.gov, refreshes daily, and drops active solicitations after about a week — all of which tell the agent when this source is the right one and when recency matters. It does not explicitly name an alternative tool or state exclusions ('use search_opportunities for federal notices'), so it stops short of a full when/when-not treatment.

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, yet the description still adds material context beyond them: amounts are obligations rather than cash paid, one search consumes one use regardless of result count, and every record carries a source link or ID for citation. The remaining gap is pagination behavior, since a 50-record cap with a cursor parameter is never explained.

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 opening two sentences are legal/affiliation boilerplate, so the actual purpose statement is not front-loaded. The middle content is dense and earns its place, but the non-affiliation and no-recommendation framing occupies roughly half the text and pushes operational details like the record cap and sourcing to the tail.

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 an output schema the description need not describe return shape, and annotations cover safety, but a 13-parameter search tool with zero required fields needs at least a note on how filters combine and how to page via cursor/limit. That operational gap keeps it at minimum-viable for its complexity.

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 23% across 13 parameters, so the description must carry the load, and it names only three filters (trade lane/naics, agency, contractor). It says nothing about piid, office, keyword, award_key, solicitation, sort, or the cursor used for paging, leaving the majority of the surface undocumented in both places.

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 second sentence gives a specific verb+resource: historical federal prime award records from USAspending, with 'who won what, for how much, from which agency.' The word 'prime' implicitly separates it from search_subawards and list_reported_subawards, but no sibling is named, so an agent must infer the boundary against search_ota_awards, list_awards_by_period_end, or get_record on its own.

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?

'Filter by trade lane, agency, or contractor name' is filter inventory, not a when-to-use rule. The description does add hard usage constraints (present as information only, no bid/no-bid or eligibility framing), which is real guidance, but there is no explicit statement of when to prefer this over adjacent tools such as search_subawards or get_record.

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 bar is lower. The description adds genuinely non-obvious behavior: the billing/rate-limit model (30-minute follow-up window, one accepted call = one use regardless of result count), the data provenance caveat, and the guarantee that each record carries a source link for citation. Only the exact return shape is left implicit, which the output schema covers.

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 purpose is front-loaded, but the opening three sentences of legal non-affiliation disclaimer consume significant space before any functional information appears. The rate-limit sentence is dense and detail-heavy for a search tool, though it does carry real 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?

With an output schema present, return values needn't be explained, and the description covers provenance, citations, disclaimer posture, and billing semantics. The one omission is guidance on the limit/maximum behavior, which matters for a paginated search but is left entirely to the schema.

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 67% with agency and vendor already described in the schema as substring filters, which the description merely restates. The 'limit' parameter (default 20, max 50) is undocumented in both schema and description, so the description does not compensate for the remaining 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 and resource: cancelled contracts with claimed savings, drawn from public cancellation reports, filterable by agency or vendor. The resource is precise enough to distinguish it from the other cancelled-record siblings (search_cancelled_grants, search_cancelled_leases) without naming them, but it never explicitly routes the agent among those closely-named tools.

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?

"Filter by agency or vendor" and "verify against official records before acting" imply usage context, and "Present as information only" constrains how results should be surfaced. However, there is no statement of when to choose this over the cancelled-grants or cancelled-leases siblings, nor any prerequisite conditions for calling it.

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 (readOnly, idempotent, non-destructive), so the description earns credit for the extra context it supplies: data provenance caveats, a 'verify before acting' instruction, per-record source links for citation, and an explicit quota model (one accepted call = one use; 30-minute follow-up window). The one real gap is that 'grants recorded as cancelled' does not clarify how incomplete or lagged the underlying source reports are beyond the generic disclaimer.

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 of the opening four sentences are near-duplicate legal disclaimers ('Not affiliated with the U.S. government, GSA, or SAM.gov' / 'Not a U.S. government service'), which delays the actual purpose. The quota and source-link sentences are dense but each carries real information. Front-loading should be the capability, not the disclaimer.

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?

An output schema exists, so return-value explanation is correctly omitted. The description covers provenance, citation, quota mechanics, and filter dimensions, which is most of what an agent needs. It is slightly thin on what happens with zero matches or whether pagination exists beyond the limit cap of 50.

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 67%: agency and recipient carry their own 'substring filter' descriptions, but limit has no schema description at all. The description only restates 'filter by agency or recipient' and adds nothing about substring matching behavior, nullability, or what the limit bounds mean. Since the schema already does most of the work, a 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 states a specific resource and scope: grants recorded as cancelled, including claimed savings, drawn from public cancellation reports. The resource type implicitly separates it from search_cancelled_contracts and search_cancelled_leases, though it never names those alternatives explicitly. The purpose is buried behind two sentences of legal disclaimer, but it is unambiguous once reached.

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 says the results can be filtered by agency or recipient, which implies a lookup use case, but gives no explicit when-to-use vs. when-not guidance. It does not tell the agent when to prefer search_cancelled_contracts, search_cancelled_leases, or search_grants_gov over this tool. The rate-limit note ('follow-ups within 30 minutes ride free') hints at iterative refinement but is framed as billing, not workflow 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?

Beyond the read-only annotations, the description discloses provenance (public cancellation reports), data caveats (figures as reported, verify against official records), direct source links for citation, and a detailed billing model for follow-up searches. These are meaningful behavioral traits an agent would not know from the annotations alone.

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 informative but front-loads two legal-disclaimer sentences before stating the tool's purpose, which delays clarity. The billing and verification details are useful but make the description dense, and some phrasing is repetitive.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema and rich annotations, the description provides enough context about data source, caveats, filtering, billing, and source links for an agent to invoke the tool responsibly. It stops short of explicitly positioning the tool relative to sibling search tools, which is the main remaining 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?

The schema already documents agency and location as substring filters, and the description merely restates 'Filter by agency or location' without adding syntax or format guidance. The limit parameter is undocumented in both the description and schema, though its bounds are clear from the schema. With moderate schema coverage, this is adequate but not additive.

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 the resource: federal leases recorded as cancelled, with claimed savings, sourced from public cancellation reports. It also mentions filtering by agency or location. It does not explicitly differentiate itself from sibling tools like search_cancelled_contracts or search_cancelled_grants, which prevents 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?

Usage is implied by the resource and filter options, and the description adds a caution to verify figures and present as information only. However, it provides no explicit guidance on when to use this tool versus the closely related cancelled-contract or cancelled-grant search tools.

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 read-only/idempotent/non-destructive safety profile, so the bar is lower, yet the description still adds genuinely useful behavior: 'one search counts as one use' (a quota/cost signal), every record carries a source link or record ID for citation, and an explicit instruction that results are informational only. It does not mention pagination or how limit interacts with usage counting.

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 first two sentences are redundant disclaimers ('Not affiliated with the U.S. government, GSA, or SAM.gov' / 'Not a U.S. government service'), consuming the front-loaded position that should carry the purpose. The genuinely useful quota and citation facts are buried mid-paragraph. Tightenable to roughly half the length.

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?

An output schema exists so return structure needn't be explained, and the description still covers eligibility, sector scope, quota cost, citation/verification affordance, and a compliance caveat. Gaps are minor: no mention of the 50-record cap or how limit interacts with result counts.

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% — query and status are documented in the schema, limit is not. The description's 'filter by keyword or status' merely restates the two documented params and adds no semantics (no status value guidance beyond the schema's 'e.g. open, forecasted', no hint about what limit controls). Baseline 3 given the schema does most of the work.

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 agency (Denali Commission) and resource (grant opportunities) with a clear scope: rural Alaska infrastructure, energy, transportation, health, sanitation, housing. This is enough for an agent to distinguish it from the many other agency-specific search_* siblings (search_dra_grants, search_nbrc_grants, search_mcc) without opening schemas, though it never explicitly contrasts itself with any of them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives filtering guidance ('Filter by keyword or status') and a caution to verify eligibility and deadlines before acting, which implies usage context. But it never states when to use this search versus the sibling agency searches, nor when to escalate from this list tool to get_grant_record for full record detail — that routing is left to inference.

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?

Adds substantial context beyond the read-only annotations: status is computed from recorded deadlines rather than live verification, unknown deadlines are dropped under non-'all' statuses, billing is one search = one use regardless of result count, and every record carries a source link for citation. The non-affiliation disclaimer and 'information only' framing further set expectations.

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 largely waste-free, but the first two sentences are legal disclaimers placed before the actual capability statement, delaying the front-loaded purpose. Every sentence still carries information an agent may need.

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 7-parameter, all-optional search tool with a full output schema, the description covers source, filters, deadline semantics, billing, and verifiability. Nothing an agent needs to call it correctly or interpret results is 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 the baseline is 3; the description adds value by naming the filter facets (keyword, NSN, solicitation, buyer code) and clarifying that status reflects recorded deadlines, not live verification. It does not explain match_mode's acronym behavior, which stays only in the schema, so it is a modest rather than full addition.

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 ('Defense Logistics Agency simplified-acquisition RFQs from DIBBS') and enumerates the domain ('parts, medical, clothing, subsistence'). It also distinguishes itself from other notice sources by noting these 'rarely appear on SAM.gov', so an agent can separate it from search_opportunities/search_grants_gov style 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?

Gives clear context for when this source is the right one (small DLA purchases absent from SAM.gov) and explains the status filter caveat that unknown deadlines only appear with status=all. It stops short of explicitly naming an alternative tool to use for SAM.gov notices, so routing is implied rather than fully prescribed.

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?

Adds substantial context beyond the annotations: freshness cutoff (October 2025), billing semantics ('one search counts as one use, regardless of how many records are returned'), and output provenance ('every record carries a direct source link or source name and record ID'). These are genuinely useful behavioral facts an agent cannot infer from the readOnly/idempotent/openWorld annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Content is relevant but the first two sentences are legal disclaimers occupying the front-loaded position, delaying the actual purpose. The billing and sourcing notes are valuable but the paragraph mixes compliance, scope, freshness, and citation concerns without strong structure. Every clause is defensible, but the ordering undermines front-loading.

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 an output schema present, return-value shape needn't be explained, and the description covers freshness, billing, and citation provenance. For a 5-param filtered search over a public dataset this is nearly complete; only explicit sibling routing would close the 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 80%, so the schema already documents org, fain, query, and agency descriptions. The description's filter list maps onto these parameters but adds no syntax, matching behavior, or format detail beyond what the schema provides. Baseline 3 is appropriate given the schema carries the parameter 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?

States a specific verb and resource: individual federal grant payment disbursements from public payment reports, with the filterable dimensions called out. It also distinguishes itself from the cancellation siblings by explicitly noting 'These are disbursements made, not cancellations,' which helps route away from search_cancelled_grants. It doesn't name the closest data siblings, keeping it at 4 rather than 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?

Gives concrete use conditions: filter by agency, recipient org, keyword, or FAIN, and discloses that the feed is historical and stopped meaningful updates around October 2025. This tells the agent both how to query and when the data is not appropriate. No explicit 'use X instead' sibling routing beyond the cancellations note, so not 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, so the description earns credit for what it adds beyond them: the billing model ('one search counts as one use, regardless of how many records are returned'), the provenance guarantee (every record carries a direct source link or source name plus record ID, enabling verification and citation), and the field-level payload (deadlines, award ranges, eligibility, source links). The non-affiliation disclaimer also preempts a factual error an agent might otherwise make about the source.

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 but largely purposeful, and it front-loads the non-affiliation disclaimer. The opening three sentences restate the same disclaimer twice ('Not affiliated...' and 'Not a U.S. government service'), which delays the actual purpose statement to sentence two. Trimming that redundancy would make the definition stronger without losing legal coverage.

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?

An output schema exists, yet the description still summarizes what comes back (deadlines, award ranges, eligibility, source links) and how to present it. Combined with coverage of provenance, billing, and scope boundaries for a five-parameter, zero-required search tool, nothing an agent needs in order to call and use this correctly is 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 80% and the description maps its filter axes onto the parameters (keyword, program, record type, recipient state), which is at or above baseline. It goes further by spelling out program full names (SEDAP, Community Infrastructure Fund, Delta Workforce Grant Program, Strategic Planning, disaster-recovery addenda) where the schema only gives abbreviations, adding real disambiguation value. It does not, however, explain the limit cap or how record_type interacts with the state filter (state only applies to award records per 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 (DRA grant funding cycles and announced awards), enumerates the exact programs covered (SEDAP, CIF, DWP, Strategic Planning, disaster-recovery addenda), and explicitly distinguishes itself from Grants.gov listings. An agent can tell this apart from search_grants_gov, search_open_grants, and search_nbrc_grants without 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?

Gives clear selection context: these awards go to local governments, nonprofits, and tribes across eight named states and are NOT listed on Grants.gov, which implicitly routes the agent here instead of the federal grants sibling. It also specifies the four filter axes and a presentational constraint ('information only; do not frame results as an eligibility determination'). No explicit exclusion statement naming a competing sibling for the overlap case, so 4 rather than 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, open-world, idempotent, non-destructive behavior, so the bar is lower, yet the description still adds real context: FDIC is not FAR-bound, awards are not reported to FPDS so award history is limited, and every record carries a source link for verification. The 'one search counts as one use regardless of records returned' note discloses a quota/billing trait not present in annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening two sentences are redundant legal disclaimers ('Not affiliated with the U.S. government, GSA, or SAM.gov. Not a U.S. government service.') that repeat the same idea, and the actual purpose statement is buried after them. The remainder is informative, but the front-loading is wasted on boilerplate.

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?

An output schema exists, so return-value explanation is unnecessary, and the description supplies the caveats an agent needs (limited award history, verify against the official notice, source links per record). The main gap is that nothing explains the limit parameter or result-set behavior, which matters for a search tool capped at 50 records.

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%: 'query' is documented in the schema as a keyword filter over notice title, and the description's 'Filter by keyword' merely echoes that. The 'limit' parameter (1–50, default 20) is undocumented in both places, so the description does not compensate for the coverage gap. Baseline 3 applies.

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 identifies a specific resource and scope: FDIC solicitations posted to SAM.gov under CORHQ numbers, with a note on what FDIC typically buys. The verb is implied ('Filter by keyword') rather than stated, and it does not explicitly contrast with sibling search_open_notices, but an agent can tell which dataset this covers.

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 says to filter by keyword and to present results as information only with verification, which implies research/discovery usage. However, it never states when to choose this over the many sibling search_* tools (e.g., search_open_notices, search_award_history) or when this source is insufficient, leaving routing to inference.

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 the description adds real context beyond them: abstracts-only content with no full text, a per-call usage cost ('one search counts as one use, regardless of how many records are returned'), and verifiable source links per record. The non-affiliation disclaimer clarifies provenance, not behavior, but the quota and abstract-only caveats are genuinely useful disclosures.

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?

Content is mostly worthwhile, but the legal disclaimer occupies the opening position ahead of what the tool actually does, and the final sentence about source links overlaps with the earlier mention of 'a link to the full document'. Slight redundancy and a back-loaded purpose section cost it 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?

With an output schema present the return fields needn't be restated, yet the description still lists them, and it covers scope, content caveats, quota behavior, and citability. Only the absence of routing guidance relative to the many sibling search tools leaves a 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 75% and the schema already documents keyword matching, doc_type values, published_since format, and limit bounds. The description only echoes 'Filter by keyword' and never mentions doc_type, date filtering, or result limits, so it adds little 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 names the resource specifically: 'Procurement-relevant Federal Register documents: FAR rulemaking, acquisition policy notices, and Procurement List (AbilityOne) actions.' That scope is concrete and distinguishable from SAM.gov-style siblings like search_open_notices, though no sibling is named 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?

It implies usage ('Filter by keyword') and gives one important follow-up rule ('Abstracts only, read the full document before acting'), but never states when to choose this over search_open_notices, search_grants_gov, or get_notice_record, nor any exclusions.

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, open-world, idempotent, and non-destructive behavior. The description adds useful context beyond that: it is a keyless feed, one search counts as one use regardless of record volume, records carry source links or IDs for verification, and results should be verified against official postings. It stops short of details like rate limits 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?

The disclaimer is front-loaded and the description is organized, but there is redundancy: 'Not affiliated with the U.S. government, GSA, or SAM.gov' and 'Not a U.S. government service' convey nearly the same point. Several sentences are legal/verification boilerplate rather than tool-selection 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?

Given a search tool with an output schema, annotations, and 83% schema coverage, the description is largely complete. It covers data source, refresh origin, return fields, billing semantics, verification expectations, and disclaimers. It could be improved by explicitly routing to sibling search tools, but no critical calling information is 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 83%, so the schema already does most parameter documentation work. The description adds only broad filter categories (keyword, agency, deadline) and does not explain match_mode, include_forecast, or limit behavior beyond what the schema provides.

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+resource: grant opportunities from the public Grants.gov feed, including posted and forecasted federal postings, refreshed from the keyless Grants.gov API. It is clear what the tool retrieves, though it does not explicitly distinguish itself from closely named siblings such as search_open_grants or search_dra_grants.

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?

Says to filter by keyword, agency, or deadline, which implies usage, and adds presentation caveats about not treating results as eligibility determinations. However, there is no explicit when-to-use-this-vs-an-alternative guidance naming sibling tools or exclusion 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 declare read-only, idempotent, non-destructive behavior, but the description adds substantial context: provenance from MCA portals, non-FAR procurement rules, different protest rights, U.S. bidder eligibility, per-search usage counting, and source-link verification. These are meaningful behavioral disclosures beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description contains useful legal/provenance context, but it repeats the non-affiliation and non-FAR points across several sentences. The core purpose and filtering guidance are present, yet the front-loaded disclaimers make it longer and less direct than it could be.

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 search tool with an output schema and rich annotations, the description covers provenance, verification expectations, filters, notice-type interpretation, and source-link availability. It misses explicit sibling routing and the omitted `rei`/`limit` details, but the overall context is largely 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 75%, and the schema already documents `query`, `country`, and `notice_type` including the `rei` value. The description adds useful plain-language meanings for `gpn`, `spn`, and `ca`, but omits `rei` and does not explain `limit`, so it only partially improves parameter 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 states a specific verb and resource: searching MCC compact procurement notices from partner-country MCA entities. It clearly distinguishes these from U.S. federal/FAR procurements and names the issuing entities, so an agent can identify the tool's domain immediately.

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 explains how to filter by keyword, country, and notice type, and clarifies that GPNs are pipeline forecasts rather than live bids. It does not explicitly route the agent to `search_mcc_forecast` or other sibling tools, so sibling selection still requires inference.

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?

Goes well beyond the existing readOnly/idempotent annotations by disclosing that results are informational and non-binding, that every record carries a source link or ID for verification, that one search counts as one use regardless of result count, and that eligibility should be confirmed with the issuing MCA entity. These are non-obvious behavioral and quota facts an agent needs before acting.

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 legal disclaimer is front-loaded, which is defensible, but the core message is repeated: 'INFORMATIONAL AND NON-BINDING,' 'These are forecasts, not live solicitations,' and 'Present as information only' say the same thing three times. Trimming the redundancy would make it tighter without losing meaning.

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 the forecast nature, eligibility, verification, and quota semantics, and an output schema exists so return values need not be described. The one remaining gap is the limit parameter's behavior (default 20, max 50) and any paging semantics, which are unaddressed in both schema and description.

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 description restates the filter dimensions (keyword, country, anticipated quarter), which the schema already documents for three of four parameters. It adds no format or syntax detail beyond the schema, and the limit parameter is undocumented in both places. With 75% schema description coverage, 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?

States a specific resource (MCC Partner Country Business Forecast of planned compact procurements above $300K) and its source/publisher. It clearly frames the content as forecasts rather than live solicitations, which implicitly separates it from live-opportunity siblings. It stops short of naming the sibling (e.g., search_mcc or search_opportunities) it differs from, so sibling differentiation is inferred rather than explicit.

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?

Gives clear context for when to use it: early-market intelligence on planned MCC procurements, filtered by keyword, country, or quarter, with the note that real opportunities post later as live bids. It does not explicitly route the agent to a specific alternative tool for live bids, and no exclusions are stated, so it is clear but not fully prescriptive.

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 establish readOnly/idempotent/openWorld, and the description adds real value beyond them: data provenance and coverage limits, the fact that other sources miss this money, a usage-accounting rule ('one search counts as one use, regardless of how many records are returned'), and a deadline-verification obligation. It stops short of describing result shape or ordering, which is acceptable given an output schema exists.

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?

Every sentence carries information, but the first two sentences are a legal disclaimer that delays the actual purpose until the third sentence – poor front-loading for a tool definition. The closing compliance instructions are useful but lengthen an already dense paragraph.

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 four-parameter filtered search with an output schema, the description supplies the provenance, scope, caveats, and usage rules an agent needs. The only notable omission is pagination/limit behavior, which is left to the schema.

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 75% and the schema already documents query, program, and open_only. The description's 'filter by keyword, program, or open rounds' merely restates those three and adds no syntax or edge-case detail, while limit (max 50, default 20) is undocumented in both places. 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?

States a specific verb and resource (NBRC grant programs and award announcements from nbrc.gov) and enumerates the covered programs (Catalyst, Forest Economy, Timber for Transit). It also draws an explicit boundary against the obvious alternatives, noting NBRC posts nothing to Grants.gov and does not appear under its own name in USAspending, which tells an agent why to pick this over search_grants_gov.

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?

Gives clear when-to-use context (NBRC money in ME/NH/VT/NY distressed counties) and when-not-to-substitute (do not present results as eligibility determinations or application recommendations; grants only, no contracts). It does not name sibling tools directly, but the Grants.gov/USAspending comparison implicitly routes the agent, so it stops short of full explicit alternative naming.

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, open-world, non-destructive behavior. The description adds useful context: legal non-affiliation disclaimer, billing note that one search counts as one use, returned fields, and source-link verification. It does not cover authentication or rate limits, so 4 rather than 5.

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 dense and mostly useful, but it opens with two similar legal-disclaimer sentences before stating the core purpose. It is not bloated, but front-loading could be improved.

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 an output schema and annotations present, the description covers safety, verification, billing, and return fields adequately. It leaves gaps around match-mode behavior and sibling-tool selection, but is otherwise complete for an open-world search 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 75%, with detailed descriptions for limit, agency, and keyword; match_mode has only an enum. The description adds no parameter-specific meaning, 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 states the resource clearly: open grant opportunities from public grant sources in GovInbox's database, and lists the returned fields. It does not explicitly distinguish this from sibling grant-search tools such as search_grants_gov or search_dra_grants, 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?

It gives instructions on how to present results (information only, verify facts) but does not say when to use this tool versus the many sibling grant-search tools. There is no explicit alternative or exclusion guidance beyond the general open-grants scope.

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?

Beyond the readOnly/idempotent/openWorld annotations, it discloses the quota model in detail (3/day and 10/month unauthenticated; 20/month with a free account), what consumes a use (empty results, retries, additional pages), what does not (rejected auth, exhausted quota, nonexistent record lookups), and the 30-minute follow-up window. It also discloses the data-coverage limitation ('not a complete live search of SAM.gov') and that results are sorted by date, not match score.

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 lead disclaimer is correctly front-loaded, but the body is bloated: 'One accepted search counts as one use, regardless of the number of records returned' appears twice verbatim, and the quota passage spans many sentences that could be compressed into two. Signal is present but buried in repetition, working against scannability.

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 an output schema present, rich annotations, and full schema parameter coverage, the description fills the remaining gaps an agent needs: licensing/quota constraints, data-coverage caveats, source-link verifiability for citation, and the paging/retry cost model. Nothing needed to invoke it correctly or interpret limits is 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%, so the baseline is 3. The description nonetheless adds genuine semantics the schema lacks: the NAICS digit-prefix mapping examples, the instruction that VOSB and SDVOSB are distinct and must not be substituted, and the warning not to infer certifications from a veteran-owned request. The sort-by-date caveat and set_aside/default behavior are already covered by the schema, so it stops short of 5.

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 specific verb and resource: 'Searches open federal contract notices in GovInbox's stored SAM.gov data using the supplied NAICS and optional filters,' and states the return shape ('published notice facts and source information'). It does not explicitly contrast with near-siblings such as search_opportunities or search_open_grants, so the differentiation is implicit 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?

It gives operative routing rules: map industry words to NAICS prefixes with concrete examples (construction -> 23; IT services -> 5415), states a free-text keyword is not a substitute for NAICS, and specifies exactly how to encode 'veteran-owned' versus 'service-disabled veteran-owned' via set_aside. It also states when-not: no bid recommendations, no eligibility determination, no partner suggestions, and follow-up work belongs to other calls.

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/openWorld, and the description adds substantial context beyond them: stored-notice engine shared with search_open_notices, records are not a complete live-source or version-history search, legacy DIBBS records may lack verified deep links, and billing semantics (free follow-ups within 30 min up to 30 per search, otherwise one accepted call = one use). These are behavioral traits not inferable from annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is dense and mostly valuable, but the structure is poor: it opens with two legal disclaimers before stating what the tool does, and splices in fragments like 'Present as information only; not a bid recommendation' mid-paragraph. Purpose should be front-loaded, not preceded by boilerplate.

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 an output schema present, return-value explanation isn't required, yet the description still describes card contents, deadlines, matched filter, and source links. Pagination (cursor) and edge cases (legacy DIBBS records, closed/archived inclusion, billing follow-ups) are all addressed, so nothing an agent needs to call correctly is 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 already 90%, so the baseline is 3, but the description genuinely extends meaning for naics (prefix mapping strategy), set_aside (vosb vs sdvosb distinction, unrestricted requires affirmative evidence), and the solicitation_number vs notice_id distinction. It does not cover match_mode, leaving one enum undocumented in both places.

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 clear verb and resource: search open federal contract opportunities from SAM.gov notices, presented as cards. It distinguishes itself from search_open_notices by noting results are sorted by posted date/deadline rather than match score, but it never explicitly says when to choose this tool over that sibling. Purpose is clear but sibling differentiation is only partial.

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?

Rich conditional guidance: map trade words to NAICS prefixes with concrete examples, use NAICS rather than free-text keywords, pass both vosb and sdvosb for 'veteran-owned' but only sdvosb for service-disabled, use solicitation_number for reference numbers and notice_id for SAM notice IDs with the note that these exact lookups include closed records. This is explicit when-to-use guidance for parameters and modes.

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 only declare read-only/idempotent/open-world, and the description adds substantial operational context on top: FPDS as source, ~90-day reporting lag, obligated dollars being action deltas rather than ceiling values, the consortium-manager attribution caveat, a verification-link guarantee, and an explicit quota model (30-minute follow-up window, one accepted call = one use). This is exactly the behavior an agent needs before deciding to spend a call.

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 content density is high and nearly every sentence carries information, but the purpose statement is buried behind two legal-disclaimer sentences and the remainder runs as one dense block mixing provenance, caveats, quota rules, and verification guidance. Restructuring so the verb+resource leads and the disclaimers/quota move to the end would improve scannability without losing content.

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, open-world search with an output schema already covering return shape, this description supplies everything else an agent needs: source, known data-quality traps, temporal lag, dollar semantics, citation path, and cost model. Nothing material is 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 80% so the baseline is 3; the description adds real meaning by restating the filter dimensions and, more importantly, by warning that the vendor parameter matches the consortium management organization rather than the performer. That reframes what a match on `vendor` actually means, which the schema does not convey. The `limit` cap of 50 and the nullability defaults remain undocumented in prose.

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?

Names a specific verb+resource (search DoD Other Transaction Authority awards) and enumerates the agreement families covered (research, prototype, production). It also draws a hard boundary against adjacent datasets by stating these agreements bypass the FAR and never appear in USAspending, which tells an agent it cannot get this from the standard award tools.

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 states what you can filter on and gives a strong interpretation rule for the vendor field, but it never names a sibling tool or a when-not-to-use condition (e.g., use search_award_history or search_sole_source for FAR-based awards, get_notice_record for opportunities). Usage is implied by the data-domain description rather than routed explicitly.

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?

Goes well past the readOnly/idempotent annotations: discloses that parsed vendor names and values may be incomplete, that below-threshold and exempt actions never post, that one search counts as one use regardless of result count, and that every record carries a source link for verification. It also carries an explicit non-affiliation disclaimer, which is behavioral context an agent needs before presenting results.

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 substantive content is dense and valuable, but two sentences of legal non-affiliation boilerplate lead the description, pushing the actual purpose back. The long em-dash-chained sentences mix timing, caveats, filters, billing, and verification into a single stream, making it less scannable than it could be.

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 search tool with a full output schema and rich annotations, nothing material is missing: record timing, field-reliability caveats, false-negative interpretation, billing unit, and verification path are all covered.

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 86% schema description coverage, the schema already explains query, agency, vendor, naics, authority, and bridge_only. The description restates the filter set and adds FAR authority examples (6.302-1 only one source, 6.302-2 urgency), but does not add syntax, matching behavior, or defaults beyond the schema. 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?

States a specific verb and resource: it searches Justification & Approval (J&A) notices from SAM.gov, and defines what those are (documents agencies publish to justify non-competitive awards). The scope — sole-source/post-decision records rather than opportunities — is enough to separate it from siblings like search_opportunities and search_award_history.

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?

Gives strong context on when this data is and isn't useful: usually posted 14/30 days after award, not a pipeline lead, protest clock may have run, and empty results don't imply competition. It never names a specific alternative sibling tool to use instead for pipeline work, 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?

Beyond the annotations, the description adds substantial behavioral context: it warns that amounts are prime-reported, often incomplete or duplicated, and not cash paid or obligations. It also states that one search counts as one use regardless of record count and that every record carries a source link for verification, which is valuable operational detail not present in annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description contains useful content but is a single long paragraph that front-loads legal disclaimers before the tool's purpose. It also repeats the partnership caveat ('Not a partnership suggestion' and later 'do not frame results as ... partnership recommendation'), which reduces efficiency.

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?

The description is adequate for understanding the core data and its caveats, and an output schema exists to cover return values. However, with 10 parameters and only 30% schema description coverage, the description leaves several invocation details unexplained and does not help agents choose among similar siblings.

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 low at 30%, so the description should compensate for undocumented parameters. It only mentions filtering by prime contractor name, leaving parameters such as piid, sort, cursor, date_to, keyword, and subaward_number unexplained in the description; the schema titles alone provide limited semantic help.

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 the resource: individual reported first-tier subaward records showing which subcontractor worked under which prime and for how much. It is specific about scope and filtering by prime contractor, but it does not explicitly distinguish itself from similar siblings such as list_reported_subawards or find_teaming_partners.

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 gives output-use constraints such as 'Present as information only' and 'do not frame results as a bid/no-bid recommendation', but it does not explain when to use this tool instead of similar siblings. There is no explicit when-to-use or when-not-to-use guidance, only implied usage from the record description.

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