Find federal opportunities, research awards and vendors, and review dated exclusion evidence.
Scored across 12 tools
Most tools have clearly distinct purposes, especially the exclusion-related workflows and opportunity research tools. The main overlaps are generic search versus search_exclusions/search_opportunities, and detail versus document, but the descriptions provide enough context to disambiguate.
Many tools follow a clear snake_case verb_noun pattern, such as check_exclusions, search_opportunities, and explain_match. However, single-word names like detail, document, freshness, and search break the pattern, and saved_searches uses an adjective_noun form, creating a mixed but still readable convention.
Twelve tools is well within the ideal range for a domain-specific research server. Each tool contributes a distinct capability, from discovery and retrieval to exclusion analysis, provenance reporting, and saved-search management, without feeling bloated or sparse.
The tool surface covers the full read-only research lifecycle: searching across entity types, retrieving records and documents, explaining matches, investigating exclusions, checking provenance, and managing saved searches. No critical dead ends are apparent for the stated government-research domain.
Check up to 20 identities against a dated active SAM snapshot. Exact identifier matches and name-only possible matches remain distinct. No match is not clearance.
| Name | Required | Description | Default |
|---|---|---|---|
| generation | No | ||
| identities | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, open-world, idempotent, and non-destructive, and the description adds valuable behavioral context: the check uses a dated active SAM snapshot, accepts up to 20 identities, keeps exact versus name-only matches distinct, and clarifies that no match is not clearance. This meaningfully extends the annotation coverage.
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 three short sentences with no filler. It front-loads the core action, then adds the match-type distinction and an important caveat; every sentence 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?
The description covers the essential invocation context: subject, input size, snapshot timing, match categories, and the no-match-is-not-clearance limitation. It is mostly complete for a read-only batch check tool, but the generation parameter remains underspecified and no usage alternatives are mentioned, so it is not fully 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?
The description adds some meaning to the identities parameter by stating the 20-identity limit and explaining exact identifier versus name-only matching. However, schema description coverage is 0%, and the generation parameter is not explained at all in either the schema or the description, so the description only partially compensates.
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 action — checking up to 20 identities against a dated active SAM snapshot — and adds meaningful distinctions between exact identifier matches and name-only matches. It is clear about the tool's purpose, though it does not explicitly differentiate itself from sibling tools like search_exclusions or search.
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 intended use is implied: batch-check exclusion identities against a snapshot. However, no explicit when-to-use versus alternatives, such as search_exclusions or exclusion_changes, is provided, and there is no when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a known public identifier. Supply generation from search for a consistent result.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| collection | Yes | ||
| generation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey readOnly, openWorld, idempotent, and non-destructive behavior. The description adds a useful nuance: supplying the generation from search yields a consistent result, which matters in an open-world context. It does not explain error cases or what happens when generation is null.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler, and the operational guidance about generation is front-loaded in the second sentence. It is appropriately terse, though the phrase 'known public identifier' is noticeably opaque.
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 zero parameter descriptions, no enums, and no output schema, the description alone is too thin for an agent to confidently populate collection and id. It covers the generation workflow but leaves essential invocation details and return expectations unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden of explaining parameters. It explains generation's source and purpose, but collection and id are left essentially undefined beyond the generic phrase 'known public identifier,' leaving required parameters under-specified.
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 concrete action ('Retrieve') but the object is framed as 'a known public identifier,' which is vaguer than the title's 'federal record.' It does not distinguish this tool from siblings like document or search, and the resource being retrieved is only indirectly implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Supply generation from search for a consistent result' gives a useful situational cue: use detail after a search and pass the generation value. However, it does not explicitly say when not to use detail, nor does it name an alternative tool for lookup-style tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read bounded official record text by known identifier. Does not fetch arbitrary URLs or paths.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| length | No | ||
| offset | No | ||
| collection | Yes | ||
| generation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive behavior. The description adds a meaningful boundary ('does not fetch arbitrary URLs or paths') and 'bounded', but does not disclose output shape, pagination behavior, or generation semantics. No contradiction with 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?
Two short sentences, front-loaded with the core behavior and ending with a guardrail. No filler; every word contributes.
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 five parameters, no output schema, and no parameter descriptions, the description is too thin for an agent to invoke correctly. It omits collection semantics, range/pagination parameters, generation behavior, and return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning. It only implies 'id' via 'known identifier' and 'official record' for collection, leaving length, offset, and generation completely unexplained. This is insufficient for five parameters.
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 uses a specific verb ('Read'), resource ('official record text'), and scope ('by known identifier'), and adds an exclusion for arbitrary URLs/paths. It is clear, though it does not name a sibling alternative like 'detail' to fully differentiate.
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 clearly indicates the intended use case: reading a known official record identifier. It also states when not to use it ('Does not fetch arbitrary URLs or paths'). However, it does not explicitly route to any alternative sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two retained snapshots. No longer observed does not mean reinstated; enrichment-only changes are excluded.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | ||
| to_generation | No | ||
| from_generation | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld/idempotent annotations, the description adds crucial non-obvious behavior: 'no longer observed does not mean reinstated' and enrichment-only changes are excluded. This materially prevents misinterpretation of results and is exactly the kind of behavioral context an agent needs.
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 with zero filler. The core action is front-loaded, and the second sentence delivers high-value caveats. 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?
The core concept is clear, but with 4 parameters, 0% schema coverage, and no output schema, the description omits important invocation details: pagination via limit/cursor, default to_generation behavior, and what the returned changes actually look like. This is not complete enough for fully self-contained use.
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 0% description coverage, so the description must compensate. It only indirectly references 'from_generation' and 'to_generation' as 'two retained snapshots' and provides no meaning for 'limit' or 'cursor', nor any default behavior for 'to_generation'. This leaves most parameter semantics to inference.
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 a specific action ('Compare two retained snapshots') and names the resource being compared. The caveat about enrichment-only changes adds useful semantic precision, though it does not explicitly differentiate the tool from sibling tools like search_exclusions or exclusion_context.
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 for when to use the tool: when comparing two retained snapshots. It does not mention alternatives or exclusionary conditions, so it falls short of a 5, but the context is unambiguous enough for an agent to identify the intended use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve an exclusion with agency explanation, named restriction references, source evidence and supported business links.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| generation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the specific data scope (agency explanation, named restriction references, source evidence, supported business links), which is useful context beyond just 'retrieve'. However, it does not disclose other behavioral aspects like error handling, pagination, or the meaning of the 'generation' parameter. Since annotations cover the main safety and the description adds some context, a 3 is appropriate.
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, efficient sentence that front-loads the action ('Retrieve an exclusion') and then lists the content components without any filler. Every clause contributes value, and the structure is clear and scannable. No waste.
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 two parameters (one required) and no output schema. The description lists the data components that will be returned, giving some idea of the output structure, but it does not explain the parameters or clarify the role of 'generation'. Without an output schema, an agent must rely on the description to understand the response, and while the component list helps, it is not enough to fully prepare an agent to call the tool correctly, especially given the lack of parameter semantics. A 3 is appropriate for a retrieval tool with this level of ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning neither 'id' nor 'generation' has any documentation in the schema. The description does not explain either parameter; it only implies through the tool name that 'id' identifies the exclusion, but it never states that explicitly. The 'generation' parameter is completely unexplained. With zero schema coverage, the description carries the full burden for parameter semantics but fails to compensate.
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 ('Retrieve') and resource ('an exclusion') and enumerates the exact data components returned (agency explanation, named restriction references, source evidence, supported business links). This is clearer than a generic 'get' but does not explicitly differentiate from siblings like 'detail' or 'document', which might also retrieve similar content.
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 offers no guidance on when to use this tool versus the many siblings (e.g., check_exclusions, explain_match, detail). It does not state any conditions, exclusions, or alternatives. An agent would have to infer the intended use solely from the name and the data list, which is insufficient given the tool's position among 11 siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain deterministic primary NAICS overlap between a registered vendor and opportunity. Not an eligibility determination.
| Name | Required | Description | Default |
|---|---|---|---|
| vendor_id | Yes | ||
| opportunity_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds meaningful context beyond annotations, namely that the explanation is 'deterministic' and limited to 'primary' NAICS, but it does not disclose output format, error conditions, or prerequisites. This is comparable to the 'date-range' case in calibration, so a 3 is appropriate.
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 purpose in the first and a boundary clarification in the second. No filler, every clause earns its place, and the structure is front-loaded and easy to parse.
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 is simple (2 required string params, no output schema), and the description states the core purpose and a limitation. However, without an output schema, the description does not explain what the returned 'explanation' looks like or what happens if vendor_id is not registered, leaving some ambiguity for an agent deciding whether to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, leaving the description to define vendor_id and opportunity_id. The description only implies that vendor_id refers to a 'registered vendor' and opportunity_id to an 'opportunity.' It does not explain ID formats, how to obtain valid IDs, or any constraints, so it only partially compensates for the absent schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Explain') and resource (deterministic primary NAICS overlap between a registered vendor and opportunity), and the closing clause 'Not an eligibility determination' further distinguishes it from broader judgment tools. This makes the tool's scope immediately identifiable.
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 a clear when-not ('Not an eligibility determination') and implies when to use it (needs an explanation of primary NAICS overlap). It does not explicitly name alternative sibling tools, but the exclusion signals the boundary well enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report actual source dates, coverage, record counts and SHA256 provenance.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior, so the description need not repeat those safety traits. It adds value by naming the exact reporting dimensions (source dates, coverage, record counts, SHA256 provenance), which go beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that wastes no words; every phrase ('actual source dates,' 'coverage,' 'record counts,' 'SHA256 provenance') adds 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?
For a parameterless reporting tool, the description covers the essential facts an agent needs to decide to invoke it. It lacks an explicit output format, but the listed report contents are sufficient given the tool's simplicity and read-only annotations.
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 zero parameters and 100% schema coverage, there are no parameter semantics to document; the baseline for parameterless tools applies. The description is not required to explain inputs and instead clarifies what the tool reports.
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 uses a specific verb ('Report') and enumerates precise output contents: actual source dates, coverage, record counts, and SHA256 provenance. This clearly distinguishes it from sibling tools like search or detail, which do not promise provenance/coverage metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to choose this tool over siblings such as detail, document, or explain_match. There are no scenarios, prerequisites, or exclusions stated, so the agent must infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a cited research brief with retained notice requirements, exact award-number candidates and same-industry comparisons. Does not infer an incumbent or eligibility.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| generation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior, so the description does not need to restate those. It adds useful boundary context by saying the tool will not infer an incumbent or eligibility, but it stops short of describing the return format or how the 'generation' parameter affects behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences front-load the deliverable and then add one clarifying negation. Every clause carries information, with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameter-level descriptions in the schema, the description must carry more weight. It explains the nature of the brief, but omits what 'id' and 'generation' mean and provides no mention of the response shape or invocation conditions, leaving it under-specified for reliable autonomous use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description never names 'id' or 'generation', the only two parameters. An agent cannot tell what identifier to pass or what the nullable 'generation' value controls, making the tool difficult to invoke correctly.
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 ('Build') and a precise deliverable ('cited research brief') with three concrete components: retained notice requirements, award-number candidates, and same-industry comparisons. The negative boundary ('Does not infer an incumbent or eligibility') further differentiates it from sibling tools that might be used for those inferences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or alternatives are mentioned. The 'Does not infer' clause is a useful boundary but not a clear routing instruction, so an agent gets little help deciding between this tool and siblings like search_opportunities, detail, or document.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage private saved opportunity searches: list/create/events/delete/rotate_feed/delete_workspace. Requires Authorization Bearer workspace key configured in the client headers, never tool arguments. Ask before creating or deleting. Public research tools do not require this key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | ||
| name | No | ||
| criteria | No | ||
| operation | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true, and the description adds meaningful context beyond that by disclosing the Authorization bearer workspace key requirement, the placement in client headers, and the need to ask before creating or deleting. This is useful behavioral context not present in 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 is compact: the main purpose and operation list are front-loaded in the first sentence, and the auth requirement and caution follow quickly. It avoids filler while packing useful details, though the operation list is a little dense.
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 multi-operation dispatch tool with no output schema and low schema coverage, the description should clarify how id, name, and criteria relate to each operation. It covers auth and destructive behavior but leaves the main parameter relationships undefined, so an agent cannot reliably construct calls for all operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the four parameters. It lists possible operation values, which partially covers the 'operation' parameter, but it never explains the meaning or intended use of id, name, or criteria, leaving significant gaps.
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 uses the generic verb 'Manage' but anchors it to a specific resource, 'private saved opportunity searches,' and enumerates the specific operations: list/create/events/delete/rotate_feed/delete_workspace. It also distinguishes these private saved searches from 'Public research tools', which separates it from sibling search 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?
The description gives clear context: this tool operates on private saved searches and requires a workspace key set in client headers, not tool arguments. It also instructs the agent to ask before creating or deleting and notes that public research tools do not need this key, giving implicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search public opportunities, vendors, awards, exclusions, or reference collections. Results include provenance and a generation-pinned cursor.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| limit | No | ||
| cursor | No | ||
| collection | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and open-world behavior. The description adds useful behavioral detail beyond that: results include provenance and a generation-pinned cursor, which informs the agent about pagination and result stability. This extra context justifies a 4.
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 deliver the core scope and a key behavioral detail with no fluff. The most important information is front-loaded, making it fast for an agent to parse.
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 4 parameters, no output schema, and 11 specialized sibling tools, the description is too thin. It doesn't clarify how q, limit, or cursor should be used, nor does it explain when to use this broad search instead of search_opportunities or search_exclusions, so an agent cannot reliably select or invoke it correctly in all cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the sparse schema. It partially does by enumerating possible collection values, but it leaves q, limit, and cursor (as an input parameter) unexplained. The cursor is only mentioned in the results context, not as an input, so agents lack critical usage 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 uses a specific verb ('Search') and names concrete resources ('public opportunities, vendors, awards, exclusions, or reference collections'), making the tool's purpose clear. It does not explicitly differentiate from specialized siblings like search_exclusions or search_opportunities, so it doesn't fully earn 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?
The description gives no guidance on when to use this generic search instead of the specialized sibling tools (e.g., search_exclusions, search_opportunities). It also doesn't mention any prerequisites or exclusions, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Filter active exclusion records by agency, program, classification, geography and dates. Preserve the returned cursor and generation.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| limit | No | ||
| state | No | ||
| agency | No | ||
| cursor | No | ||
| country | No | ||
| program | No | ||
| generation | No | ||
| effective_to | No | ||
| classification | No | ||
| effective_from | No |
Find official opportunity records by keywords, industry, set-aside, state, agency and source status. Active does not imply the deadline is open.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| after | No | ||
| limit | No | ||
| naics | No | ||
| state | No | ||
| active | No | ||
| agency | No | ||
| set_aside | No | ||
| generation | No |
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_exclusionsexclusion_changesexclusion_contextresearch_opportunitysaved_searchessearch_exclusionssearch_opportunitiesapply_business_profile_updateassess_opportunity_for_businesscheck_business_exclusionsdetaildocumentexplain_matchexport_opportunitiesfind_recompetesfind_recompetes_for_businessfreshnessget_awardget_award_evidenceget_business_awardsget_business_defaultsget_business_marketget_business_profileget_market_summaryget_opportunityget_opportunity_briefget_opportunity_changesget_opportunity_compsget_opportunity_documentsget_opportunity_extractedget_vendorget_vendor_awardsget_watch_statuslookup_referencepreview_business_profile_updateresolve_identifierreview_opportunitysave_opportunity_searchsave_recompete_radarsearchsearch_awardssearch_exclusionssearch_extracted_factssearch_opportunitiessearch_opportunities_for_businesssearch_vendorstrack_opportunityupdate_award_watchupdate_recompete_radarupdate_saved_searchupdate_tracked_opportunitywatch_awardwatch_vendorexport_opportunitiesreview_opportunityapply_business_profile_updateassess_opportunity_for_businesscheck_business_exclusionsfind_recompetes_for_businessget_award_evidenceget_business_awardsget_business_defaultsget_business_marketget_business_profileget_opportunity_briefpreview_business_profile_updatesave_recompete_radarsearch_opportunities_for_businessupdate_award_watchupdate_recompete_radarwatch_awardwatch_vendorfind_recompetesget_awardget_market_summaryget_opportunity1 field changedInput schema / additionalPropertiesAdded value: +falseget_opportunity_changesget_opportunity_comps1 field changedInput schema / additionalPropertiesAdded value: +falseget_opportunity_documentsget_opportunity_extractedget_vendor1 field changedInput schema / additionalPropertiesAdded value: +falseget_vendor_awards1 field changedInput schema / additionalPropertiesAdded value: +falseget_watch_status1 field changedInput schema / additionalPropertiesAdded value: +falselookup_referenceresolve_identifiersave_opportunity_search5 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / delivery_channels / defaultRemoved value: -[
- "email",
- "in_app"
-]Input schema / properties / search_spec / additionalPropertiesRemoved value: -{}Input schema / properties / search_spec / propertyNamesRemoved value: -{
- "type": "string"
-}Input schema / properties / search_spec / typeRemoved value: -"object"search_awardssearch_exclusionssearch_extracted_factssearch_opportunities15 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / agency / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "items": {
- "type": "string"
- },
- "minItems": 1,
- "type": "array"
- }
-]New value: +[
+ {
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "minItems": 1,
+ "type": "array"
+ }
+]Input schema / properties / awarded_contractor_name / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "items": {
- "type": "string"
- },
- "minItems": 1,
- "type": "array"
- }
-]New value: +[
+ {
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "minItems": 1,
+ "type": "array"
+ }
+]Input schema / properties / awardee_cage / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "items": {
- "type": "string"
- },
- "minItems": 1,
- "type": "array"
- }
-]New value: +[
+ {
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "minItems": 1,
+ "type": "array"
+ }
+]Input schema / properties / awardee_uei / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "items": {
- "type": "string"
- },
- "minItems": 1,
- "type": "array"
- }
-]New value: +[
+ {
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "minItems": 1,
+ "type": "array"
+ }
+]Input schema / properties / cursor / minLengthAdded value: +1Input schema / properties / deadline_preset / minLengthAdded value: +1Input schema / properties / naics / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "items": {
- "type": "string"
- },
- "minItems": 1,
- "type": "array"
- }
-]New value: +[
+ {
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "minItems": 1,
+ "type": "array"
+ }
+]Input schema / properties / notice_type / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "items": {
- "type": "string"
- },
- "minItems": 1,
- "type": "array"
- }
-]New value: +[
+ {
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "minItems": 1,
+ "type": "array"
+ }
+]Input schema / properties / posted_preset / minLengthAdded value: +1Input schema / properties / psc / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "items": {
- "type": "string"
- },
- "minItems": 1,
- "type": "array"
- }
-]New value: +[
+ {
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "minItems": 1,
+ "type": "array"
+ }
+]Input schema / properties / q / minLengthAdded value: +1Input schema / properties / set_aside / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "items": {
- "type": "string"
- },
- "minItems": 1,
- "type": "array"
- }
-]New value: +[
+ {
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "minItems": 1,
+ "type": "array"
+ }
+]Input schema / properties / sort / minLengthAdded value: +1Input schema / properties / state / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "items": {
- "type": "string"
- },
- "minItems": 1,
- "type": "array"
- }
-]New value: +[
+ {
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "minItems": 1,
+ "type": "array"
+ }
+]search_vendorstrack_opportunity2 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / delivery_channels / defaultRemoved value: -[
- "email",
- "in_app"
-]update_saved_search8 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / cadence / defaultRemoved value: -"daily"Input schema / properties / delivery_channels / defaultRemoved value: -[
- "email",
- "in_app"
-]Input schema / properties / enabled / defaultRemoved value: -trueInput schema / properties / search_spec / additionalPropertiesRemoved value: -{}Input schema / properties / search_spec / propertyNamesRemoved value: -{
- "type": "string"
-}Input schema / properties / search_spec / typeRemoved value: -"object"Input schema / requiredPrevious value: -[
- "id",
- "name",
- "search_spec"
-]New value: +[
+ "id"
+]update_tracked_opportunity9 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / alert_cadence / defaultRemoved value: -"immediate"Input schema / properties / delivery_channels / defaultRemoved value: -[
- "email",
- "in_app"
-]Input schema / properties / enabled / defaultRemoved value: -trueInput schema / properties / next_action / defaultRemoved value: -nullInput schema / properties / next_action_due_at / defaultRemoved value: -nullInput schema / properties / notes / defaultRemoved value: -nullInput schema / properties / pursuit_state / defaultRemoved value: -"watching"Input schema / properties / source_profile_id / defaultRemoved value: -nullget_opportunityget_opportunity_compsget_vendorget_vendor_awardsget_watch_statussave_opportunity_searchsearch_opportunitiestrack_opportunityupdate_saved_searchupdate_tracked_opportunityGovernment contract search and federal procurement data: SAM.gov opportunities + USASpending awards.
Search U.S. federal, state, and local government procurement data and intelligence.
US federal contracting data: open solicitations, buying agencies, contractors, price history.
SAM.gov contract opportunities and entity lookup (BYOK) plus USASpending federal award data.
Add one secure layer between your agents and this server.
