BidCatch

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

With no annotations, the description carries the behavioral burden and does well: it identifies the data source, states weekly refresh cadence, and explains exact matching by name or UEI. It does not describe return fields or whether partial matches are possible, leaving some behavior unspecified.

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 tightly written sentences, front-loaded with the core action and followed by the risk rationale and matching behavior. No filler.

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

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

For a simple lookup with three optional, fully documented parameters, the description covers what is checked, why it matters, matching keys, and source freshness. Because there is no output schema, it could still say more about the return value, which keeps it from 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 100%, so the baseline is 3. The description adds useful semantic guidance beyond the schema by emphasizing exact name/UEI matching and explaining that the state filter disambiguates common names.

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 resource (SAM.gov exclusion/debarment list) and action (check for a company or person). Clearly distinguishes this compliance lookup from the forecast, award, protest, recompete, and bid-search 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?

Strongly states when to use it: before teaming with or subcontracting to anyone, with the consequence of an excluded partner poisoning a bid. It does not discuss when not to use it or name an alternative, so it falls short of the top score.

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 no annotations at all, the description carries the full burden and does substantial work: it discloses the data provenance (prime-reported subcontract records from USAspending/FSRS) and warns that these are reported relationships rather than inferred ones — a meaningful reliability caveat. The auth requirement is stated. It omits result volume, pagination, and behavior when no relationship is found, which keeps it below 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?

Three tight sentences, front-loaded with what the tool returns before the use cases and the auth note. Every sentence contributes: definition, provenance caveat, when-to-use, prerequisite.

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 purpose, directionality, data source, and access requirement for a three-parameter lookup with no output schema. The notable gap is that all three parameters are optional but the description never says at least one identifier (uei or company) is needed, nor does it sketch the return shape now that no output schema exists to do so.

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 explains uei as the strongest match key and role as prime/sub/both. The description's phrasing about primes and subs reinforces the role enum but adds no matching or resolution detail beyond what the schema states. Baseline 3 applies when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb-and-resource pair ('Find who a company teams with on federal contracts') and immediately scopes it to both directions of the prime/subcontractor relationship. That scope distinction separates it cleanly from siblings like get_award_history or search_awards, which concern awards rather than reported teaming relationships.

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 two concrete triggering scenarios: mapping an incumbent's bench before a recompete, and finding primes a subcontractor already works with. It also states the prerequisite ('Requires a BidCatch intel key'). It stops short of naming which sibling to use instead when you want award-level or forecast-level data, so it is strong context but not full 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?

With no annotations, the description carries the full burden and does well: it discloses that entries can be revised or cancelled (volatility), that the data is planning-grade rather than authoritative, and that a BidCatch intel key is required (auth prerequisite). It stops short of return format, pagination, or behavior for agencies with no forecast.

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

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

Two compact sentences, front-loaded with the core purpose before the data-quality caveat and auth requirement. Every clause carries information; nothing is redundant.

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

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

For a one-parameter read tool with no output schema, the description covers purpose, the shape of returned entries, data reliability caveats, and the auth requirement — enough for an agent to call it correctly. Only pagination/result-size behavior is left unaddressed.

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 'agency' parameter, including an example ('Interior', 'Veterans'), so the schema already does the work. The description adds no syntax, matching, or format guidance beyond what the schema provides, making the 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?

States a specific verb ('List') and resource ('an agency's published procurement forecast') and even unpacks what a forecast entry contains (planned contract actions, estimated values, timelines). It is clearly distinct from siblings like get_award_history and get_protest_record by resource, though it never names an alternative to differentiate 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?

The description implies a use case (planning-stage procurement research) but gives no explicit when-to-use or when-not-to-use guidance, and does not route the agent between this tool and search_bids or get_recompete_radar. 'Planning-grade data' hints at the context but is a data-quality caveat, not usage guidance.

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

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

No annotations are provided, so the description carries the full disclosure burden. It usefully states the auth prerequisite ('Requires a BidCatch intel key') and the search/read nature of the operation, but says nothing about result volume, pagination, or rate limits for a historical dataset that is likely large.

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 tight sentences: purpose first, use cases second, with the auth requirement appended as a short qualifier. No filler and nothing buried.

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 three-parameter read tool with no output schema and no annotations, the description covers purpose, use cases, and auth, but omits result-shape expectations (counts, pagination, sort behavior) that an agent needs to call it correctly at scale. Adequate but with clear gaps.

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

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

Schema coverage is 67%: 'query' and 'state' are documented, and 'sort' carries an enum plus default, so the schema is doing most of the work. The description adds no parameter-level detail (e.g., whether 'state' filters the recipient or the awarding agency), leaving it at the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Search') and resource ('federal contract award history') and unpacks the payload as 'who won what, for how much, and when,' which cleanly separates it from the sibling search_bids (active solicitations vs. past awards). It never explicitly names or contrasts a sibling, so it stops short of a 5.

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

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

Gives concrete use cases — 'size up incumbents, price work, or find buyers' — which tells an agent what business question this tool answers. It does not state when to prefer it over get_recompete_radar or search_bids, nor any exclusions, so it lacks the routing precision of a 5.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses an auth requirement ('Requires a BidCatch intel key') and the nature of the returned decisions, but says nothing about result volume, pagination, or rate limits for what is presumably a search endpoint.

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 sentences, front-loaded with the verb and resource, and the em-dash clause delivers the return semantics without padding. No sentence is wasted.

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

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

For a one-parameter, annotation-free search tool with no output schema, the description covers purpose, auth requirement, and the gist of the results. It stops short of describing result shape or pagination, which matters somewhat given there is no output schema to fall back on.

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?

There is a single parameter and schema description coverage is 100% — the schema already states keywords are matched against agency and case matter. The description adds no syntax, scoping, or matching-behavior detail 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 description gives a specific verb (Search) and a precise resource (GAO bid protest decisions), plus a plain-language gloss of the payload ('who challenged an award, and whether the referee sustained or denied it'). It does not explicitly differentiate itself from siblings like search_bids or get_award_history, though the protest-specific domain makes the distinction reasonably inferable.

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: an agent can infer you call this when you need GAO protest outcomes, but there is no statement of when to prefer it over search_bids or get_award_history and no exclusions. The only explicit condition given is the authentication prerequisite.

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 no annotations, the description carries the full behavioral burden. It usefully discloses a prerequisite ('Requires a BidCatch intel key') and 'List' implies a read-only operation, but it says nothing about result volume, pagination, or rate limits. The auth disclosure adds real value beyond 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?

Two compact sentences plus a short prerequisite note. The core purpose is front-loaded and every clause earns its place, with no redundancy against the schema.

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

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

For a read-only list tool with no output schema, the description covers purpose, filters, and the auth requirement adequately. It could say more about what each result contains or ordering, but nothing critical for correct invocation 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 all three parameters are fully documented in the schema. The description only restates the filter dimensions without adding format or syntax detail, 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: 'List federal contracts nearing expiration,' with the framing clause 'each one a competition about to reopen' clarifying the recompete angle. This inherently separates it from search_bids and get_award_history, 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?

Names the three filter dimensions (keyword, NAICS, state), which implies when the tool is useful, but offers no explicit when-to-use vs alternatives guidance against siblings like search_bids or get_agency_forecast. Usage is implied rather than directed.

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 no annotations, the description carries the full behavioral burden; it does disclose the auth requirement (BidCatch intel key) and the meaning of the one-bid filter, which are valuable. But it says nothing about result shape, pagination/limits, or sort behavior, and the read-only nature is only implied by 'filter'/'search'.

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

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

Three short sentences, front-loaded with the core purpose, then the routing rule, then the prerequisite. No filler; every sentence contributes distinct 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?

Covers purpose, routing, and auth, which is solid for a 6-param search with 83% schema coverage and no output schema. However, it omits anything about result volume, pagination, or what a filtered response looks like, leaving a real gap for an agent planning a query.

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% and already documents naics, state, agency, recipient, and one_bid_only, so the description's inline field list largely repeats the schema. It adds no format, matching-mode, or default guidance beyond what structured data provides, 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 resource ('Filter federal contract awards') and enumerates the exact-field dimensions (recipient, awarding agency, NAICS, state), explicitly contrasting with keyword search. An agent can distinguish this from get_award_history without opening the schema.

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

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

Gives an explicit when-to-use rule ('use this when you know the slice you want') and names the sibling alternative ('use get_award_history for topic/keyword search'). It also surfaces the prerequisite of a BidCatch intel key, which affects whether the call can succeed at all.

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 no annotations, the description carries the full behavioral burden. It does add a genuinely useful non-obvious trait — results are relevance-ranked and title matches outrank description mentions — which is not derivable from the schema. However, it is silent on result volume, pagination, whether the search is exhaustive, and any auth/rate-limit behavior.

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

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

Two short sentences, both load-bearing, with the scoping content front-loaded before the ranking note. Nothing is redundant or padded.

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 4-parameter search with no annotations and no output schema, the description covers purpose and ranking but omits result-set characteristics (pagination, count limits) and any note that the ranking rule is the only ordering available. Adequate but with clear gaps for an agent deciding how to page or how broadly to query.

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 four parameters are already fully documented, establishing a baseline of 3. The description restates the searchable dimensions (keyword/state/buyer level) and clarifies the open-vs-past distinction behind 'open_only', but adds no syntax or format detail 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?

States a specific verb ('Search') and resource ('government bid opportunities') and enumerates the three filtering axes (keyword, state, buyer level). The resource is distinct from every sibling (forecasts, awards, protests, recompete radar), so no confusion is possible without opening a 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?

The description never says when to reach for this tool versus siblings, nor does it state prerequisites or exclusions. The only usage signal is the parenthetical '(open and past)', which is folded into the purpose statement rather than presented as guidance.

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