GovGazette

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

Annotations declare readOnlyHint and idempotentHint, and the description adds important behavioral context beyond that: exact matches vs. name-only possible matches, the distinction between staleness and no_match, and the caveat that 'No match is not clearance.' This is high-value, non-obvious 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 description is a compact set of five sentences, all front-loaded with the core action and followed by precise usage constraints. Every sentence provides actionable information with zero fluff.

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 batch-checking tool with an output schema and full schema coverage, the description supplies critical behavioral nuances (possible vs. exact matches, staleness handling, no-match-not-clearance) that an agent needs to interpret results correctly. Nothing essential 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%, with each parameter described in the schema, so the baseline is 3. The description mentions the array-of-objects shape and required identity attributes, but adds no syntax or format detail beyond what the schema already 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 states a specific verb ('Check') and resource ('1 to 20 identities against a dated active SAM snapshot'), and the semantics are distinct from sibling tools like search_exclusions and explain_match. It clearly defines the batch-checking action and the scoped snapshot.

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

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

The description provides clear usage context ('Pass identities as an array of objects, not a record ID or page URL') and specifies the required identity attributes, but it does not explicitly name alternative sibling tools (e.g., search_exclusions or explain_match) or state when to use this tool over them.

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 real value by warning that synthesized identifiers (URLs/slugs/titles) will fail and that generation pins a consistent snapshot, but it says nothing about what happens on a stale generation or missing record.

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 with zero filler; the identity constraint is front-loaded and the optional consistency parameter follows. Every clause carries actionable 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 and rich annotations, the description needs only to cover the call contract, which it does: where identifiers come from and why to pass generation. Minor omission is failure-mode guidance for stale generations or unknown IDs.

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 all three parameters are already documented, including the constraint against URLs/slugs and the snapshot purpose of generation. The description restates those same semantics rather than adding new detail, so it lands 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?

Uses a specific verb+resource combination ("Retrieve a public record") reinforced by the title "Read a federal record." It is distinguishable from the search-based siblings because it describes a single-record fetch, though the generic tool name "detail" needs the description to carry that 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?

Explicitly states the precondition that collection and id must come from a prior search call, and explicitly forbids page URLs, titles, or slugs. It does not name a specific alternative sibling, but the search→detail workflow is made unambiguous.

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 is covered. The description adds real behavioral value beyond them: the chunking/pagination protocol (offset 0, fixed length cap, carry next_offset unchanged) and the bounded-fetch guarantee.

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 the core action, then pagination, then the exclusion. No redundant restatement of the name or title, and every sentence carries an instruction.

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 description is unnecessary, and the pagination mechanics are explained. Enough to call the tool correctly; the only soft spot is the ambiguous next_offset reference that an agent must map onto the response.

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, but the description adds workflow meaning the schema lacks: the exact source of collection/id/generation values and the offset/length progression. It notably references next_offset, a response field not present as a parameter, which is useful but slightly confusing.

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 ("Read official record text") and ties the operation to values returned by search, which implicitly separates it from the sibling search/detail tools. However it never names an alternative tool, so the sibling differentiation is by inference 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 operational guidance: use the exact collection/id/generation from search, start at offset 0 with length 1–16,000, then reuse next_offset. It also states an exclusion ("Does not fetch arbitrary URLs or paths"). It stops short of naming alternatives such as detail for metadata.

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), and the description adds real domain behavior: absence of observation is not treated as reinstatement, and enrichment-only changes are filtered out. That filtering semantics is genuinely useful information an agent would not get from annotations or 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?

Two short sentences with the core operation front-loaded and no filler. It is efficient, though the extreme brevity borders on under-specification for a comparison tool.

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

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

An output schema exists so return values need not be explained, and annotations cover safety. However, the description never clarifies what a retained snapshot/generation is, how to obtain the required from_generation UUID, or pagination behavior, leaving meaningful gaps for a tool with four parameters.

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 from_generation, to_generation, cursor, and limit are already documented in the schema. The description adds no additional meaning about how snapshots map to parameters, 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?

The description states a specific verb and object ("Compare two retained snapshots"), but the resource is described only as generic snapshots rather than exclusions, and it does nothing to separate itself from close siblings like exclusion_context, check_exclusions, or search_exclusions. An agent can grasp the operation but cannot confidently route to this tool over its 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?

There is no statement of when to use this tool, what prerequisites exist (e.g. needing generation UUIDs), or which sibling to prefer instead. The caveats given are about result semantics, not about selection among the many exclusion-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?

Annotations declare readOnly/idempotent/openWorld/non-destructive, so safety is covered. Description adds what the record contains (explicit source-age warnings), which is useful beyond annotations, but omits error behavior when ID is stale or missing and snapshot semantics beyond the 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?

One dense sentence listing exactly the output components, front-loaded with the core action; 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?

Output schema exists, so return structure needn't be explained. Description plus annotations plus 100% param coverage makes the tool callable, though a note on missing/stale records would complete the behavioral picture.

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 explains 'id' and 'generation'. The description adds no information about parameter behavior, 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?

Specific verb 'Retrieve' with resource 'exclusion' and enumerated payload contents (agency explanation, restriction references, source evidence, source-age warnings, business links). Clearly distinguishable from search_exclusions (which returns IDs) and exclusion_changes (which tracks changes) by emphasizing full evidence retrieval.

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?

Implied usage via schema reference ('ID returned by search_exclusions or check_exclusions') hints at the follow-up workflow, but the description itself offers no explicit when-to-use vs exclusion_changes or detail.

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 include readOnlyHint: true, idempotentHint: true, and destructiveHint: false, covering safety. The description adds value by specifying that it explains 'deterministic primary NAICS overlap' and is not an eligibility determination, which is behavioral context beyond the hints. However, it doesn't detail the exact nature of the explanation (e.g., textual vs visual) but that is partially covered by having an output schema.

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

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

The description is a single, concise sentence that is front-loaded with the core purpose and ends with a crucial caveat. Every word earns its place, with no filler or redundancy.

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 tool has an output schema, so return value specifics are covered. Given its simple two-parameter input and the annotations, the description provides sufficient context for an agent to understand what the tool does and when to use it. Minor lack: omission of explicit alternative or exclusion scenarios, but the overarching purpose is clear.

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 description coverage is 100%, meaning both parameters are described in the schema. The description does not add extra meaning beyond what's in the schema, but it does mention 'registered vendor' and 'opportunity' which aligns with the parameter descriptions. This is baseline 3 as schema already carries the semantic load.

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

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

The description clearly states the specific action ('Explain deterministic primary NAICS overlap') and the resources involved ('between a registered vendor and opportunity'). It also provides a crucial scoping caveat ('Not an eligibility determination') that distinguishes it from potential related tools like check_exclusions or research_opportunity, making the tool's specific purpose unmistakable.

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 clear context on when to use the tool: when explaining deterministic primary NAICS overlap between vendor and opportunity. However, it does not explicitly state when NOT to use it or mention alternative tools. The scoping note ('Not an eligibility determination') implies an alternative but does not name 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 declare readOnlyHint, idempotentHint, openWorldHint and non-destructive, so safety is covered. The description adds useful content about what the report contains (coverage, counts, SHA256 provenance), but says nothing about whether it hits remote sources, how current the check is, or any latency/caching behavior implied by openWorldHint.

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

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

A single front-loaded sentence that enumerates the reported fields with no filler. It is slightly telegraphic (no explicit subject/verb for the tool's purpose), but every word earns its place.

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

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

With an output schema present, the description need not explain return values, and it does not need to cover parameters. What remains thin is the openWorld dimension — an agent might want to know this reaches external sources and may be slow — but otherwise an agent can call this 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 tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. It correctly avoids inventing parameter semantics that the empty schema does not support.

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 concrete verb-and-content set — reporting source dates, coverage, record counts and SHA256 provenance — which is distinct from sibling tools like search or detail. It stops short of a 5 because it never explicitly contrasts itself with siblings such as detail or document, so the agent must infer the boundary.

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

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

There is no statement of when this tool should be called, when it should not, or which sibling to use instead (e.g., detail or document for record-level inspection). The 'freshness' name plus 'actual source dates' only weakly implies a data-currency check.

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, openWorld, non-destructive), so the bar is lower, and the description still adds genuine behavioral content: outputs are cited, notice requirements are retained, and it explicitly refuses to infer incumbent or eligibility. That last point is a real capability boundary an agent would otherwise assume. It does not mention latency or depth limits, keeping it at 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?

Two sentences, no filler, with the positive capability statement front-loaded and the exclusion clause second. Every clause carries 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?

An output schema exists, so return-value explanation is unnecessary, and annotations plus full schema coverage handle safety and parameters. Combined with the description's scope and boundary statements, an agent has enough to invoke it correctly; only explicit sibling routing 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 both parameters (id and generation, including the 'retained generation UUID from search_opportunities' provenance) are fully documented in the schema. The description adds no parameter-level meaning beyond the schema, 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?

The description names a specific verb ('Build') and concrete artifact ('cited research brief') and enumerates its contents: retained notice requirements, exact award-number candidates, same-industry comparisons. It also bounds itself negatively ('Does not infer an incumbent or eligibility'), which helps distinguish it from inference-style siblings like explain_match, though no sibling is named directly.

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

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

Usage is implied rather than stated: an agent can infer this is the deep-research call to make after search_opportunities, and the negative clause warns of what it will not answer. There is no explicit 'use this instead of detail/document' routing or prerequisite statement, so 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?

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral detail — results carry provenance and the cursor is generation-pinned, meaning pagination is stable against index changes — which is exactly the kind of context annotations cannot convey.

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, no filler. The scope of searchable collections comes first and the result-shape note second, which is the right front-loading order.

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 full schema coverage, the description needn't explain return values, and it correctly restricts itself to the pagination/provenance caveat. The one missing piece is routing guidance versus the specialized search_* siblings, which matters given how many of them exist.

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 q, limit, cursor, and collection are all documented in the schema, establishing the baseline of 3. The description's collection enumeration mirrors the schema's own examples and adds no syntax, format, or defaulting detail 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 (search) and enumerates the resource families it covers (opportunities, vendors, awards, exclusions, reference collections), which is far more informative than the bare name. It doesn't differentiate itself from the specialized siblings search_opportunities and search_exclusions, so an agent can't tell from this text alone whether this is the general-purpose entry point or a duplicate.

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 collection list: it hints that this tool spans multiple collections, while the siblings are collection-specific. There is no explicit 'use this when searching across collections' or 'prefer search_opportunities for opportunity-only queries' statement, and no prerequisites or exclusions are given.

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, open-world). The description adds genuinely useful behavior beyond that: pages may come back smaller than limit with page_size_limited true, cursor must be paired with unchanged filters, and the data is 'dated evidence, not clearance' — a meaningful validity caveat. It stops short of describing freshness staleness thresholds.

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

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

Front-loaded with the purpose sentence, then pagination mechanics, then the freshness/validity caveat. Slightly dense with internal jargon (page_size_limited, coverage.freshness, generation) and mildly redundant with the limit and cursor schema descriptions, but no filler sentences.

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 description covers pagination, cursor discipline, snapshot/generation retention, and a warning about data recency. The only real gap is disambiguation from the many sibling search/check 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 description coverage is 100%, so every one of the 11 parameters is already documented, making 3 the baseline. The description restates the filter facet categories but adds no syntax, accepted values, or matching semantics beyond the schema, so it neither compensates nor improves.

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 active exclusion records' — and enumerates the filterable facets (agency, program, classification, geography, dates). It does not, however, distinguish itself from the close sibling check_exclusions, which likely returns a single match versus this list/filter behavior, so an agent must infer the boundary.

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 clear operational guidance for the paginated loop ('Continue with next_cursor and unchanged filters and limit'), which implies this is a multi-page list tool. But it never says when to choose it over check_exclusions, search, exclusion_changes, or exclusion_context, leaving the sibling-selection decision 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 this is a read-only, idempotent, open-world search, so the safety profile is covered. The description's one behavioral addition—clarifying that 'active' means source status, not an open deadline—is genuinely useful but largely repeats the schema description for the `active` parameter.

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 with the core scope front-loaded in the first clause and the single caveat trailing it. No filler, no redundancy in structure.

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 all nine parameters fully documented, the description needn't explain return values; the annotation set covers safety. It is nearly complete, only missing sibling routing and any mention of pagination intent (after/limit), which the schema handles.

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 every parameter (q, naics, state, set_aside, agency, generation, after, limit) is already documented. The description only lists filter categories at a high level and adds no syntax, format, or interaction details 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 (Find) plus resource (official opportunity records) and enumerates the filterable dimensions, so the agent knows exactly what it returns. However, it does not differentiate itself from sibling tools like 'search' or 'research_opportunity', which likely overlap, leaving the agent to guess which one 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?

The only guidance is a caveat ('Active does not imply the deadline is open'), which tells the agent how to interpret a flag, not when to use this tool versus siblings. With 'search', 'research_opportunity', and 'detail' in the sibling set, the absence of any routing advice is a real gap.

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