Search US government contracts, grants and jobs from matchawards.com. Read-only, no key.
Scored across 10 tools
Each tool targets a distinct resource and action: four search tools split cleanly by domain (contracts, grants, jobs, awards), get_opportunity vs assess_opportunity vs get_company vs find_teaming_partners operate on clearly different inputs and outputs, and lookup_naics and show_results are unique. Descriptions explicitly cross-reference sibling tools with 'Do not use for...' notes, resolving any residual overlap.
Uniform snake_case verb_noun pattern throughout: search_contracts, search_grants, search_jobs, search_awards, get_company, get_opportunity, assess_opportunity, find_teaming_partners, lookup_naics, show_results. Verb choices (search/get/assess/find/lookup/show) are consistent and predictable.
10 tools is well within the ideal range and each earns its place: four scoped search tools, three single-record/enrichment tools, a NAICS resolver, a partner finder, and a results presenter. No redundant or filler tools.
Strong lifecycle coverage for a discovery domain: search across all four opportunity/award types, detail retrieval, qualification assessment, partner discovery, firm history, and a results presenter. Minor gaps like saved searches, alerts, or any way to retrieve contact details (explicitly unavailable) are workaroundable, and there is no create/update surface, though none is expected for this read-only server.
Use this when the user asks whether to bid on one opportunity, or wants a qualification brief on it: days left, set-aside, AI fit notes, similar past awards, the firms that typically win such work and the usual award value.
Pass the id from a search result, and optionally my_naics (up to 10 codes) and my_set_aside to check the fit. Similar awards come from MatchAwards' award records for the same NAICS at the same agency, or at all agencies when that agency has none (basis says which); sample gives the dates covered and whether every matching record was read, so state that span rather than a longer one. Award records may be incomplete, so say so; ai text is AI-generated, so label it. Never call a firm the incumbent: these are firms that won similar work. Example: id="117412688283576625".
Print url, sam_url and each award's url and source_url as markdown links.
Do not use for searching (search_contracts, search_grants), for finding partners (find_teaming_partners) or for job postings.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The id field of a search result. | |
| my_naics | No | Up to 10 six-digit NAICS codes, comma-separated, e.g. '236220' or '541511,541512'. A record matches on its own codes (matched_naics says which). Unknown codes are ignored. | |
| my_set_aside | No | The user's set-aside code, e.g. 'SBA' or 'SDVOSBC', to compare with the opportunity's. |
| Name | Required | Description |
|---|---|---|
| ai | No | AI-generated notes on this opportunity, or null. Label them as AI-generated when you show or quote them. |
| note | No | |
| as_of | No | |
| basis | No | 'same NAICS and agency', 'same NAICS, all agencies', or null (no NAICS). |
| sample | Yes | |
| warning | No | Set when the award lookup was cut short; the figures cover what was read. |
| naics_match | No | Whether the opportunity's NAICS is one of my_naics; null when my_naics was not given. |
| opportunity | Yes | |
| coverage_note | No | |
| similar_awards | Yes | The 5 newest similar awards. |
| set_aside_match | No | Whether the opportunity is set aside for my_set_aside; null when it was not given. An opportunity without a set-aside is open to all firms. |
| typical_winners | Yes | Up to 5 firms that won similar work, most awards first, then largest total. |
| award_value_range | No | Quartiles of the similar awards' amounts (USD); null with fewer than 3 amounts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety (readOnly, idempotent, non-destructive), and the description goes well beyond them: it discloses the provenance rule for similar awards (same NAICS at same agency, falling back to all agencies, with basis indicating which), that sample reports the date span and completeness, that award records may be incomplete and AI text is generated — both requiring disclosure to the user — plus the incumbent-wording restriction and markdown link formatting.
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 usage trigger and deliverables, then parameter guidance, then output/caveat instructions and exclusions. Dense but every clause is operational; the caveat about stating sample span rather than a longer one is unusually long-winded for the value it adds.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values needn't be defined, yet the description still covers the input source, optional fit parameters, grounding caveats for the award and AI content, output formatting, and sibling exclusions. Nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so id, my_naics and my_set_aside are already fully documented. The description restates the id source and the up-to-10-codes limit, adding only an example id string and framing my_naics/my_set_aside as a fit check. Baseline 3 is appropriate when the schema carries the parameter burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (assess one opportunity) and immediately enumerates the deliverables: days left, set-aside, AI fit notes, similar past awards, typical winning firms, usual award value. The closing exclusions naming search_contracts, search_grants, find_teaming_partners and job postings make it unmistakable versus 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?
Opens with an explicit trigger ("Use this when the user asks whether to bid... or wants a qualification brief") and closes with explicit when-not routing to three named sibling tools. Both directions of the routing decision are spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants possible teaming partners, subcontractors or primes for one opportunity: firms that won similar awards in the same state or at the same agency.
Pass the id from a search result, and optionally role (sub, prime or any). Returns up to 10 firms from MatchAwards' award records (same NAICS in the opportunity's state, then at its agency, else anywhere; sample gives the dates covered and whether every matching record was read), ranked by how many similar awards they won, each with a why line; get_company(uei) shows the history of a firm with a uei. No contact details. Award records may be incomplete, so say so; ai_subcontracting is AI-generated, so label it. Never call a firm the incumbent. Example: id="117412688283576625".
Print the opportunity's url and sam_url as markdown links.
Do not use for searching awards in general (search_awards), for one firm's history (get_company) or for job postings.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The id field of a search result. | |
| role | No | sub: the user looks for subcontractors (smaller typical awards first among equals); prime: for a prime to join (larger first); any (default). | any |
| Name | Required | Description |
|---|---|---|
| note | No | |
| role | Yes | |
| as_of | No | |
| sample | Yes | |
| warning | No | Set when the award lookup was cut short; the list covers what was read. |
| partners | Yes | Up to 10 firms that won similar work. |
| opportunity | Yes | |
| coverage_note | No | |
| ai_subcontracting | No | AI-generated notes on subcontracting angles for this opportunity, or null. Label them as AI-generated when you show them. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial context beyond that: the 10-firm cap, the ranking logic and fallback order, that contact details are absent, that award records may be incomplete, and that ai_subcontracting is AI-generated and must be labeled. It also gives a hard usage rule ('Never call a firm the incumbent'), which is exactly the kind of behavioral constraint annotations cannot express.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but front-loaded: the trigger condition leads, followed by behavior, caveats, and exclusions. Most sentences earn their place, though it is on the long side and the markdown-link formatting instruction is a slightly jarring insertion mid-paragraph.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description needn't explain return values, and it instead covers everything else an agent needs: fallback ordering, ranking, data-quality caveats, labeling rules, and the required URL formatting. Nothing material 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 coverage is 100%, so both parameters are already fully documented, including the detailed role enum semantics. The description's 'Pass the id from a search result, and optionally role' largely restates the schema; the example id="117412688283576625" adds a small format cue. Baseline 3 is appropriate since 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?
States a specific verb and resource ('Find teaming partners... firms that won similar awards in the same state or at the same agency') with a precise scope. It distinguishes itself from sibling tools by naming search_awards and get_company as separate concerns. An agent can identify this tool 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?
Opens with an explicit trigger ('Use this when the user wants possible teaming partners... for one opportunity') and closes with explicit exclusions naming the alternatives ('Do not use for... search_awards... get_company... or for job postings'). Both when-to-use and when-not-to-use are covered with named siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants one firm's government award history and its UEI is known, e.g. from a search_awards row.
Returns the firm's name and other spellings, location (city, state, country), totals for contract and grant awards, first and last award dates, top NAICS codes and agencies, and its 10 most recent awards. No contact details. Award records may be incomplete, so say so. Example: uei="C3KXNLTAAY98".
Print each recent award's url and source_url as markdown links.
Do not use for finding firms by name or NAICS (search_awards) or for contact details (none are available).
| Name | Required | Description | Default |
|---|---|---|---|
| uei | Yes | 12-character UEI, e.g. 'C3KXNLTAAY98'. |
| Name | Required | Description |
|---|---|---|
| uei | Yes | |
| duns | No | |
| name | No | |
| note | No | |
| as_of | No | |
| totals | No | |
| location | No | |
| top_naics | No | From contract awards only. |
| other_names | No | Other spellings in award records. |
| top_agencies | No | |
| coverage_note | No | |
| recent_awards | No | Up to 10, newest first. |
| last_award_date | No | |
| first_award_date | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely non-obvious context: no contact details are returned, and award records may be incomplete so the agent should caveat results. It stops short of describing pagination or truncation of the top NAICS/agency lists.
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-loads the when-to-use condition and keeps the exclusion last, which is good ordering. It is slightly long because it enumerates returned fields and adds a presentation instruction ('Print each recent award's url and source_url as markdown links'), but each sentence carries actionable content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description does not need to enumerate return values, yet it still lists them usefully and covers the main risk (incomplete records) plus the UEI provenance. Nothing critical for correct invocation is missing, although the return list is partly redundant with the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already supplies the pattern and the exact same example ('C3KXNLTAAY98'). The description's only addition is provenance ('e.g. from a search_awards row'), which is mildly useful but does not go beyond the schema in any substantive way, 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?
States a specific verb and resource ('one firm's government award history') and explicitly scopes it to when the UEI is known. It distinguishes itself from search_awards by naming the alternative for name/NAICS lookup, so an agent can route without opening either 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 trigger ('when the user wants one firm's ... and its UEI is known, e.g. from a search_awards row') plus explicit exclusions ('Do not use for finding firms by name or NAICS (search_awards) or for contact details'). Both the when and the when-not are named with their alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants the details of one search result, or who to contact about it.
Pass the id from a search result. Returns the result's row plus its description (up to 2000 characters), published points of contact (name and title only) and, when MatchAwards has them, ai: AI-generated notes on fit, subcontracting and large-prime angles and a summary. AI text is AI-generated: label it as such whenever you quote it. Example: id="117402307943537453".
Print url, and sam_url for federal notices, as markdown links.
Do not use for searching (search_contracts, search_grants, search_jobs) or for contact details beyond the published names and titles.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The id field of a search result. |
| Name | Required | Description |
|---|---|---|
| ai | No | AI-generated notes on this opportunity, or null. Label them as AI-generated when you show or quote them. |
| id | Yes | Pass to get_opportunity for the description and contacts. |
| url | No | The posting on matchawards.com. Show it as a markdown link. |
| city | No | |
| note | No | |
| type | No | federal, state, grant or job. |
| as_of | No | |
| naics | No | On state notices (type state) the naics code itself is AI-assigned. |
| state | No | |
| title | No | |
| agency | No | |
| office | No | |
| sam_url | No | The SAM.gov notice (federal only). Show it as a markdown link. |
| contacts | No | Published points of contact; [] if none. |
| agency_id | No | The agency's MatchAwards id. |
| posted_at | No | Date, YYYY-MM-DD. |
| set_aside | No | |
| description | No | Up to 2000 characters. |
| matched_naics | No | Only when you filtered by naics: the requested codes this record carries: its own code (in naics) or, for a grant or job, another code of its program or occupation. |
| ai_matched_naics | No | Only when you filtered by naics: requested codes this contract notice matched only because MatchAwards' AI suggested them, not its own codes. Call such a match AI-suggested. |
| no_fixed_deadline | No | true: the deadline is a placeholder date. |
| response_deadline | No | Date, YYYY-MM-DD; null if none. |
| solicitation_number | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, but the description adds real non-obvious context: description truncation at 2000 characters, contacts limited to name and title, AI-generated notes available only when MatchAwards has them, and the mandatory labeling of AI text when quoted. It does not cover error behavior or rate limits.
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 trigger condition, then required input, then returns, then output formatting, then exclusions. Every paragraph earns its place, though the 'no searching' restriction is stated twice (first sentence and final sentence).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup with an output schema, the description covers everything an agent needs: trigger condition, input source, return contents, AI-text labeling obligation, link formatting, and boundaries against sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the id is already documented, but the description adds provenance ('pass the id from a search result') and a concrete example value, which tells the agent where the id comes from rather than just its type.
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+resource: fetch the full details of one search result by id, including its contacts. It is immediately distinguishable from the search_* siblings, since it explicitly scopes itself to a single row that already came from a 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?
It states when to use it ('when the user wants the details of one search result, or who to contact about it') and when not to (searching, or contact details beyond published names/titles), naming the search alternatives. However, it never distinguishes itself from the closest sibling, assess_opportunity, which also operates on a single opportunity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user describes a line of work in words and a NAICS code is needed, or asks what a code or code prefix covers.
query is words (2 to 100 characters; common terms such as cybersecurity or janitorial list their usual codes first) or 2 to 6 digits (every six-digit code starting with them). limit is 1 to 25, default 10. Pass the codes as naics to search_contracts, search_grants, search_jobs or search_awards.
Print each opportunities_url that is set as a markdown link.
Do not use for searching opportunities or awards themselves (the search tools take the codes).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of codes to return, 1 to 25. | |
| query | Yes | Words, e.g. 'cybersecurity', or the first 2 to 6 digits of a code, e.g. '5415'. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| as_of | No | |
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so safety is covered. The description goes beyond them by disclosing ranking behavior ('common terms such as cybersecurity or janitorial list their usual codes first'), prefix-expansion behavior for digits, and a required output presentation step (print each opportunities_url as a markdown link).
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 triggering condition and free of filler, but the middle paragraph is tightly packed and mixes query semantics, limits, and cross-tool routing into dense clauses. Still, every sentence carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need no explanation, annotations cover the safety profile, and the description supplies usage triggers, query semantics, routing to consumers, and output formatting. Nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds real meaning beyond the schema: the 2-100 character bound is restated with a concrete purpose, and it explains that a 2-6 digit query returns every six-digit code starting with those digits. The 'usual codes first' ordering for common words is also semantics the schema does not carry.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence names a specific verb+resource (look up a NAICS code) and states the two triggering intents: describing a line of work in words, or asking what a code/prefix covers. It is clearly distinguishable from the sibling search_* tools, which it explicitly routes codes to.
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 explicit when-to-use ('the user describes a line of work in words and a NAICS code is needed'), explicit when-not-to-use ('Do not use for searching opportunities or awards themselves'), and names the alternative tools to hand codes to. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks who won government contracts or grants: past awards by NAICS, agency, state, awardee name or UEI, with amounts and dates.
Filters: type (contract_award, grant_award or any), naics (up to 10 codes), agency (a name; the note says which agency it matched), state, awardee (part of a name), uei, keyword (matched in the title; a grant award's title is its recipient's name), awarded_within_days (1 to 1095, default 365), limit (1 to 50, default 20). If has_more is true, call again with cursor=next_cursor and the same filters. Example: naics="541512", agency="Department of Veterans Affairs". Pass several NAICS codes in one call.
Award records may be incomplete, so say so. Head a grant award with its awardee name and CFDA number, not its title. Pass an awardee's uei to get_company for its full history.
Print each award's url and source_url as markdown links.
Do not use for open opportunities to bid on (search_contracts, search_grants) or for one firm's history when its UEI is known (get_company).
| Name | Required | Description | Default |
|---|---|---|---|
| uei | No | The awardee's 12-character UEI. | |
| type | No | contract_award (federal contracts), grant_award, or any (both). | any |
| limit | No | Number of results to return, 1 to 50. | |
| naics | No | Up to 10 six-digit NAICS codes, comma-separated, e.g. '236220' or '541511,541512'. A record matches on its own codes (matched_naics says which). Unknown codes are ignored. | |
| state | No | Two-letter US state code of the place of performance. | |
| agency | No | Agency name, e.g. 'Department of Veterans Affairs'; matched to the closest MatchAwards agency, which the result note names. | |
| cursor | No | next_cursor from the previous response. Pass it with the same filters to get the next page. | |
| awardee | No | Part of the awardee's name, 2 to 100 characters. | |
| keyword | No | 2 to 100 characters matched against the title only. | |
| awarded_within_days | No | Only awards from the last N days, 1 to 1095 (default 365). |
| Name | Required | Description |
|---|---|---|
| note | No | |
| as_of | No | When the API generated the results (ISO time). |
| results | Yes | |
| warning | No | Set when paging stopped early; the results so far are still valid. |
| has_more | Yes | true: call again with cursor=next_cursor and the same filters. |
| next_cursor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the description correctly spends its words on what annotations cannot express: pagination behavior ('If has_more is true, call again with cursor=next_cursor and the same filters'), a data-quality caveat ('Award records may be incomplete, so say so'), and the agency-name fuzzy-match note. That is substantive behavioral context beyond the 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?
Front-loaded purpose sentence, then a tight filter inventory with defaults, then pagination, then caveats and routing exclusions. It is long, but every block carries distinct information and the trailing markdown-link instruction is a concrete output requirement rather than 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?
An output schema exists, so return values rightly go unexplained, yet the description still covers the operational essentials an agent needs: has_more/next_cursor continuation, ambiguous-agency handling, incomplete-record disclosure, and the sibling boundary. For a 10-parameter open search with 0 required parameters, that is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds semantics the schema does not: a grant award's title is its recipient's name (which changes how keyword behaves), the matched_naics/matched-agency result notes, and the guidance to batch several NAICS codes in one call. It re-enumerates the filters somewhat redundantly, keeping it at 4 rather than 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
'past awards by NAICS, agency, state, awardee name or UEI, with amounts and dates' is a specific verb+resource+filter scope, and the description explicitly contrasts itself with search_contracts, search_grants and get_company, so it is distinguishable from siblings 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?
It states the triggering condition ('when the user asks who won government contracts or grants') and names the exclusions with the alternatives to use instead ('Do not use for open opportunities to bid on (search_contracts, search_grants) or for one firm's history when its UEI is known (get_company)'). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants US federal or state government contract opportunities to bid on: bids, RFPs, solicitations, set-asides.
Filters: naics (up to 10 codes), state, keyword (title only), set_aside (federal only), type (federal or state), posted_within_days (1 to 180), open (default true), agency (a name; the note says which agency it matched), limit (1 to 50, default 20). If has_more is true, call again with cursor=next_cursor and the same filters. Example: naics="238160", state="VA", keyword="roof". Pass several NAICS codes in one call.
Print each result's url, and sam_url for federal notices, as markdown links.
Do not use for grants (search_grants), jobs (search_jobs) or one result's details (get_opportunity).
When you are done searching, call show_results once with the best ids; it shows them as a card the user can pick from.
| Name | Required | Description | Default |
|---|---|---|---|
| open | No | true (the default): only items with a response deadline of today or later, US Eastern; an item with no deadline counts as closed. false: include closed ones. | |
| type | No | Narrow to federal or to state contracts. Leave empty for both. | |
| limit | No | Number of results to return, 1 to 50. | |
| naics | No | Up to 10 six-digit NAICS codes, comma-separated, e.g. '236220' or '541511,541512'. A notice matches on its own codes (matched_naics says which), or through a code MatchAwards' AI suggested: that one is listed in ai_matched_naics, so call the match AI-suggested. Unknown codes are ignored. | |
| state | No | Two-letter US state code, e.g. 'VA'. Many federal notices have no state, so this filter skips them. | |
| agency | No | Agency name, e.g. 'Department of Veterans Affairs'; matched to the closest MatchAwards agency, which the result note names. | |
| cursor | No | next_cursor from the previous response. Pass it with the same filters to get the next page. | |
| keyword | No | 2 to 100 characters matched against the title only. | |
| set_aside | No | Set-aside code, e.g. 'SBA' or 'SDVOSBC'. Federal contracts only. | |
| posted_within_days | No | Only items posted in the last N days, 1 to 180 (default 180). |
| Name | Required | Description |
|---|---|---|
| note | No | |
| as_of | No | When the API generated the results (ISO time). |
| results | Yes | |
| warning | No | Set when paging stopped early; the results so far are still valid. |
| has_more | Yes | true: call again with cursor=next_cursor and the same filters. |
| next_cursor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/destructive/idempotent safety, so the bar is lower. The description adds real behavioral context beyond that: pagination semantics (has_more/cursor), the note that explains which agency and NAICS matched, that ai_matched_naics covers AI-suggested codes, and that unknown NAICS are ignored.
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 trigger sentence, then filters, then exclusions, then output instructions. The filter enumeration duplicates the schema somewhat, but the ordering is logical and no sentence is purely 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 10-param search tool with an output schema and full annotation coverage, the description supplies everything an agent needs: selection criteria, exclusions, pagination rules, and the required markdown-link rendering plus show_results follow-up.
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 fully documents each parameter with defaults and constraints; the description's filter list is largely a recital of the same fields. It adds only marginal value, e.g. 'Pass several NAICS codes in one call' and the open=true default praxis.
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?
Opens with a specific trigger ('the user wants US federal or state government contract opportunities to bid on') and enumerates the resource types (bids, RFPs, solicitations, set-asides). An agent can immediately separate this from search_awards, search_grants, and search_jobs.
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 names when NOT to use it and the alternative for each case (search_grants, search_jobs, get_opportunity), and adds the surrounding workflow: paginate with cursor when has_more, then call show_results once with the best ids.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants US federal grants or funding opportunities.
Filters: naics (up to 10 codes), keyword (title only), posted_within_days (1 to 180), open (default true: open grants of any age), limit (1 to 50, default 20). Grant notices carry no state. If has_more is true, call again with cursor=next_cursor and the same filters. Example: keyword="broadband". Pass several NAICS codes in one call.
Open status may lag for grants that closed recently, so check response_deadline.
Print each result's url as a markdown link.
Do not use for contracts to bid on (search_contracts) or jobs (search_jobs).
When you are done searching, call show_results once with the best ids; it shows them as a card the user can pick from.
| Name | Required | Description | Default |
|---|---|---|---|
| open | No | true (the default): only items with a response deadline of today or later, US Eastern; an item with no deadline counts as closed. false: include closed ones. | |
| limit | No | Number of results to return, 1 to 50. | |
| naics | No | Up to 10 six-digit NAICS codes, comma-separated, e.g. '236220' or '541511,541512'. A record matches on its own codes (matched_naics says which). Unknown codes are ignored. | |
| cursor | No | next_cursor from the previous response. Pass it with the same filters to get the next page. | |
| keyword | No | 2 to 100 characters matched against the title only. | |
| posted_within_days | No | Only items posted in the last N days, 1 to 180 (default 180). |
| Name | Required | Description |
|---|---|---|
| note | No | |
| as_of | No | When the API generated the results (ISO time). |
| results | Yes | |
| warning | No | Set when paging stopped early; the results so far are still valid. |
| has_more | Yes | true: call again with cursor=next_cursor and the same filters. |
| next_cursor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive, so the bar is lower, and the description still adds real behavior: grant notices carry no state, open-status can lag for recently closed grants so response_deadline should be checked, and pagination is driven by has_more/next_cursor with the same filters. It stops short of describing result cardinality or ordering, but the lag caveat is genuinely useful context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the trigger, then filters, then pagination, then exclusions, then the closing action — each sentence carries a distinct instruction. The output-format line ("print each result's url as a markdown link") is instruction rather than description, but it is one short sentence and 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?
An output schema exists, so return values need no explanation, and the description still names the response fields that drive behavior (has_more, next_cursor, response_deadline, matched_naics). For a 6-param, zero-required search tool, an agent has everything needed to call it and to chain it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter is already documented (including the subtle "no deadline counts as closed" rule and the NAICS pattern). The description mostly restates those constraints and adds only marginal value — the example keyword="broadband" and "pass several NAICS codes in one call". Baseline 3 is correct.
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 (US federal grants / funding opportunities) and scopes it geographically and by record type. It explicitly names what it is not for (search_contracts, search_jobs), so an agent can route between near-identical siblings 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?
Gives an explicit when-to-use trigger ("user wants US federal grants"), two named exclusions with the alternative tool for each, and a follow-up choreography rule ("call show_results once with the best ids"). Nothing about selection is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user is looking for a job, or for hiring signals, among postings from the last 30 days.
Filters: naics (up to 10 codes), state, keyword (title only), posted_within_days (posted within the last 1 to 30 days, default 30), limit (1 to 50, default 20). Rows carry title, agency (the employer), state, city, posted_at and url. If has_more is true, call again with cursor=next_cursor and the same filters. Example: keyword="electrician", state="TX". Pass several NAICS codes in one call.
Print each result's url as a markdown link.
Do not use for contracts (search_contracts) or grants (search_grants).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results to return, 1 to 50. | |
| naics | No | Up to 10 six-digit NAICS codes, comma-separated, e.g. '236220' or '541511,541512'. A record matches on its own codes (matched_naics says which). Unknown codes are ignored. | |
| state | No | Two-letter US state code, e.g. 'VA'. Many federal notices have no state, so this filter skips them. | |
| cursor | No | next_cursor from the previous response. Pass it with the same filters to get the next page. | |
| keyword | No | 2 to 100 characters matched against the title only. | |
| posted_within_days | No | Only jobs posted within the last N days, 1 to 30 (default 30). |
| Name | Required | Description |
|---|---|---|
| note | No | |
| as_of | No | When the API generated the results (ISO time). |
| results | Yes | |
| warning | No | Set when paging stopped early; the results so far are still valid. |
| has_more | Yes | true: call again with cursor=next_cursor and the same filters. |
| next_cursor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the burden is lighter. The description still adds value beyond them: the pagination contract via has_more/next_cursor, the filter semantics (state filter drops records with no state), and the presentation instruction to emit urls as markdown links. It does not disclose rate limits or result-ordering 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?
Front-loaded with the trigger condition, then a compact filter list, then return fields, then pagination, then exclusions. Every sentence carries a distinct instruction and none are redundant with each other.
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 enumerate return shapes, yet it still names the key row fields for planning. Pagination, filter interactions, and routing to sibling tools are all covered, leaving nothing an agent needs to 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?
Schema coverage is 100%, so baseline is 3, but the description adds operational guidance the schema lacks: the example values, the instruction to pass several NAICS codes in one call, and the note that matched_naics identifies which code hit. It also clarifies that 'agency' means the employer, which is not derivable from the schema alone.
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?
Opens with a specific trigger ('the user is looking for a job, or for hiring signals') plus a concrete resource and scope ('postings from the last 30 days'). It also names the sibling tools it is not (search_contracts, search_grants), so an agent can disambiguate without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use, explicit when-not-to-use with the alternative tools named, and a worked example (keyword="electrician", state="TX"). The pagination rule ('call again with cursor=next_cursor and the same filters') is a clear operational condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this last, after searching, to show the user the opportunities you picked as a card. Pass up to 10 ids from search_contracts or search_grants results, best first. Keep your reply to a short summary; the card shows the rows.
Ids from search_jobs or search_awards are not shown. Do not use to search (search_contracts, search_grants) or for one result's details (get_opportunity).
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | Ids from search results, in the order to show them. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| as_of | No | When the API generated the first row shown (ISO time). |
| failed | No | Ids not fetched because MatchAwards was busy or failed. Call show_results again with just these ids to add them. |
| missing | No | Ids not shown because they were not found or are not a contract or grant (a job). Retrying will not add them. |
| results | Yes | |
| warning | No | Set when some ids could not be fetched (see failed). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, but the description adds real behavioral context: a 10-id ceiling, that ordering is meaningful ('best first'), that ids from search_jobs/search_awards silently do not render, and that the user-visible card displays the rows so the reply should be a short summary. It stops short of saying what happens on a second call (replace vs. append) or on an invalid id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences, front-loaded with the sequencing rule, then the input contract, then the exclusions. No filler and no restatement of the tool name.
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 single-parameter tool with an output schema, the description covers sequencing, valid id sources, the 10-item limit, ordering, and the expected assistant reply style. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already documents order and maxItems, so baseline would be 3. The description goes further by constraining where valid ids may originate (search_contracts/search_grants results, not search_jobs/search_awards), which the schema's generic 'id field of a search result' does not convey.
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 ('show the user the opportunities you picked as a card') and immediately distinguishes itself from siblings by naming search_contracts, search_grants, and get_opportunity as the wrong tools. An agent can route to it without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit sequencing ('Use this last, after searching'), an inclusion rule (ids from search_contracts or search_grants), an exclusion rule (ids from search_jobs or search_awards are not shown), and two named alternatives to avoid (search_* and get_opportunity). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
assess_opportunityfind_contactsfind_teaming_partnersget_companyget_opportunity5 fields changedOutput schema / $defsAdded value: +{
+ "AiNotes": {
+ "description": "AI-generated notes MatchAwards wrote when it imported the notice. Every field is AI-generated text.",
+ "properties": {
+ "fit": {
+ "anyOf": [
+ {
+ "maxLength": 1000,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Who this opportunity suits.",
+ "title": "Fit"
+ },
+ "large_prime": {
+ "anyOf": [
+ {
+ "maxLength": 1000,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Angles for large prime contractors.",
+ "title": "Large Prime"
+ },
+ "reasoning": {
+ "anyOf": [
+ {
+ "maxLength": 1000,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Reasoning"
+ },
+ "subcontracting": {
+ "anyOf": [
+ {
+ "maxLength": 1000,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Angles for subcontractors.",
+ "title": "Subcontracting"
+ },
+ "summary": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/AiSummary"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ }
+ },
+ "title": "AiNotes",
+ "type": "object"
+ },
+ "AiSummary": {
+ "properties": {
+ "nft_advantage": {
+ "anyOf": [
+ {
+ "maxLength": 1000,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Nft Advantage"
+ },
+ "nft_insight": {
+ "anyOf": [
+ {
+ "maxLength": 1000,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Nft Insight"
+ },
+ "nft_title": {
+ "anyOf": [
+ {
+ "maxLength": 1000,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Nft Title"
+ }
+ },
+ "title": "AiSummary",
+ "type": "object"
+ },
+ "Contact": {
+ "properties": {
+ "name": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Name"
+ },
+ "title": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Title"
+ }
+ },
+ "title": "Contact",
+ "type": "object"
+ },
+ "Naics": {
+ "properties": {
+ "code": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Code"
+ },
+ "title": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Title"
+ }
+ },
+ "title": "Naics",
+ "type": "object"
+ }
+}Output schema / additionalPropertiesRemoved value: -trueOutput schema / propertiesAdded value: +{
+ "agency": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Agency"
+ },
+ "agency_id": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "The agency's MatchAwards id.",
+ "title": "Agency Id"
+ },
+ "ai": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/AiNotes"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "AI-generated notes on this opportunity, or null. Label them as AI-generated when you show or quote them."
+ },
+ "ai_matched_naics": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Only when you filtered by naics: requested codes this contract notice matched only because MatchAwards' AI suggested them, not its own codes. Call such a match AI-suggested.",
+ "title": "Ai Matched Naics"
+ },
+ "as_of": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "As Of"
+ },
+ "city": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "City"
+ },
+ "contacts": {
+ "description": "Published points of contact; [] if none.",
+ "items": {
+ "$ref": "#/$defs/Contact"
+ },
+ "title": "Contacts",
+ "type": "array"
+ },
+ "description": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Up to 2000 characters.",
+ "title": "Description"
+ },
+ "id": {
+ "description": "Pass to get_opportunity for the description and contacts.",
+ "title": "Id",
+ "type": "string"
+ },
+ "matched_naics": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Only when you filtered by naics: the requested codes this record carries: its own code (in naics) or, for a grant or job, another code of its program or occupation.",
+ "title": "Matched Naics"
+ },
+ "naics": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/Naics"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "On state notices (type state) the naics code itself is AI-assigned."
+ },
+ "no_fixed_deadline": {
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "true: the deadline is a placeholder date.",
+ "title": "No Fixed Deadline"
+ },
+ "note": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Note"
+ },
+ "office": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Office"
+ },
+ "posted_at": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Date, YYYY-MM-DD.",
+ "title": "Posted At"
+ },
+ "response_deadline": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Date, YYYY-MM-DD; null if none.",
+ "title": "Response Deadline"
+ },
+ "sam_url": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "The SAM.gov notice (federal only). Show it as a markdown link.",
+ "title": "Sam Url"
+ },
+ "set_aside": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Set Aside"
+ },
+ "solicitation_number": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Solicitation Number"
+ },
+ "state": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "State"
+ },
+ "title": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Title"
+ },
+ "type": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "federal, state, grant or job.",
+ "title": "Type"
+ },
+ "url": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "The posting on matchawards.com. Show it as a markdown link.",
+ "title": "Url"
+ }
+}Output schema / requiredAdded value: +[
+ "id"
+]Output schema / titlePrevious value: -"get_opportunityDictOutput"New value: +"OpportunityDetail"lookup_naicssearch_awardssearch_by_naicssearch_contracts7 fields changedInput schema / properties / agencyAdded value: +{
+ "anyOf": [
+ {
+ "maxLength": 100,
+ "minLength": 2,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Agency name, e.g. 'Department of Veterans Affairs'; matched to the closest MatchAwards agency, which the result note names.",
+ "title": "Agency"
+}Input schema / properties / naics / descriptionPrevious value: -"Up to 10 six-digit NAICS codes, comma-separated, e.g. '236220' or '541511,541512'. Unknown codes are ignored."New value: +"Up to 10 six-digit NAICS codes, comma-separated, e.g. '236220' or '541511,541512'. A notice matches on its own codes (matched_naics says which), or through a code MatchAwards' AI suggested: that one is listed in ai_matched_naics, so call the match AI-suggested. Unknown codes are ignored."Output schema / $defsAdded value: +{
+ "Naics": {
+ "properties": {
+ "code": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Code"
+ },
+ "title": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Title"
+ }
+ },
+ "title": "Naics",
+ "type": "object"
+ },
+ "OpportunityRow": {
+ "description": "One search result. Jobs fill title, agency (the employer), state, city, posted_at and url only.",
+ "properties": {
+ "agency": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Agency"
+ },
+ "agency_id": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "The agency's MatchAwards id.",
+ "title": "Agency Id"
+ },
+ "ai_matched_naics": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Only when you filtered by naics: requested codes this contract notice matched only because MatchAwards' AI suggested them, not its own codes. Call such a match AI-suggested.",
+ "title": "Ai Matched Naics"
+ },
+ "city": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "City"
+ },
+ "id": {
+ "description": "Pass to get_opportunity for the description and contacts.",
+ "title": "Id",
+ "type": "string"
+ },
+ "matched_naics": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Only when you filtered by naics: the requested codes this record carries: its own code (in naics) or, for a grant or job, another code of its program or occupation.",
+ "title": "Matched Naics"
+ },
+ "naics": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/Naics"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "On state notices (type state) the naics code itself is AI-assigned."
+ },
+ "no_fixed_deadline": {
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "true: the deadline is a placeholder date.",
+ "title": "No Fixed Deadline"
+ },
+ "office": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Office"
+ },
+ "posted_at": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Date, YYYY-MM-DD.",
+ "title": "Posted At"
+ },
+ "response_deadline": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Date, YYYY-MM-DD; null if none.",
+ "title": "Response Deadline"
+ },
+ "sam_url": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "The SAM.gov notice (federal only). Show it as a markdown link.",
+ "title": "Sam Url"
+ },
+ "set_aside": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Set Aside"
+ },
+ "solicitation_number": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Solicitation Number"
+ },
+ "state": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "State"
+ },
+ "title": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Title"
+ },
+ "type": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "federal, state, grant or job.",
+ "title": "Type"
+ },
+ "url": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "The posting on matchawards.com. Show it as a markdown link.",
+ "title": "Url"
+ }
+ },
+ "required": [
+ "id"
+ ],
+ "title": "OpportunityRow",
+ "type": "object"
+ }
+}Output schema / additionalPropertiesRemoved value: -trueOutput schema / propertiesAdded value: +{
+ "as_of": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "When the API generated the results (ISO time).",
+ "title": "As Of"
+ },
+ "has_more": {
+ "description": "true: call again with cursor=next_cursor and the same filters.",
+ "title": "Has More",
+ "type": "boolean"
+ },
+ "next_cursor": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Next Cursor"
+ },
+ "note": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Note"
+ },
+ "results": {
+ "items": {
+ "$ref": "#/$defs/OpportunityRow"
+ },
+ "title": "Results",
+ "type": "array"
+ },
+ "warning": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Set when paging stopped early; the results so far are still valid.",
+ "title": "Warning"
+ }
+}Output schema / requiredAdded value: +[
+ "results",
+ "has_more"
+]Output schema / titlePrevious value: -"search_contractsDictOutput"New value: +"SearchResult"search_grants6 fields changedInput schema / properties / naics / descriptionPrevious value: -"Up to 10 six-digit NAICS codes, comma-separated, e.g. '236220' or '541511,541512'. Unknown codes are ignored."New value: +"Up to 10 six-digit NAICS codes, comma-separated, e.g. '236220' or '541511,541512'. A record matches on its own codes (matched_naics says which). Unknown codes are ignored."Output schema / $defsAdded value: +{
+ "Naics": {
+ "properties": {
+ "code": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Code"
+ },
+ "title": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Title"
+ }
+ },
+ "title": "Naics",
+ "type": "object"
+ },
+ "OpportunityRow": {
+ "description": "One search result. Jobs fill title, agency (the employer), state, city, posted_at and url only.",
+ "properties": {
+ "agency": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Agency"
+ },
+ "agency_id": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "The agency's MatchAwards id.",
+ "title": "Agency Id"
+ },
+ "ai_matched_naics": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Only when you filtered by naics: requested codes this contract notice matched only because MatchAwards' AI suggested them, not its own codes. Call such a match AI-suggested.",
+ "title": "Ai Matched Naics"
+ },
+ "city": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "City"
+ },
+ "id": {
+ "description": "Pass to get_opportunity for the description and contacts.",
+ "title": "Id",
+ "type": "string"
+ },
+ "matched_naics": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Only when you filtered by naics: the requested codes this record carries: its own code (in naics) or, for a grant or job, another code of its program or occupation.",
+ "title": "Matched Naics"
+ },
+ "naics": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/Naics"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "On state notices (type state) the naics code itself is AI-assigned."
+ },
+ "no_fixed_deadline": {
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "true: the deadline is a placeholder date.",
+ "title": "No Fixed Deadline"
+ },
+ "office": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Office"
+ },
+ "posted_at": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Date, YYYY-MM-DD.",
+ "title": "Posted At"
+ },
+ "response_deadline": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Date, YYYY-MM-DD; null if none.",
+ "title": "Response Deadline"
+ },
+ "sam_url": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "The SAM.gov notice (federal only). Show it as a markdown link.",
+ "title": "Sam Url"
+ },
+ "set_aside": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Set Aside"
+ },
+ "solicitation_number": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Solicitation Number"
+ },
+ "state": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "State"
+ },
+ "title": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Title"
+ },
+ "type": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "federal, state, grant or job.",
+ "title": "Type"
+ },
+ "url": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "The posting on matchawards.com. Show it as a markdown link.",
+ "title": "Url"
+ }
+ },
+ "required": [
+ "id"
+ ],
+ "title": "OpportunityRow",
+ "type": "object"
+ }
+}Output schema / additionalPropertiesRemoved value: -trueOutput schema / propertiesAdded value: +{
+ "as_of": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "When the API generated the results (ISO time).",
+ "title": "As Of"
+ },
+ "has_more": {
+ "description": "true: call again with cursor=next_cursor and the same filters.",
+ "title": "Has More",
+ "type": "boolean"
+ },
+ "next_cursor": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Next Cursor"
+ },
+ "note": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Note"
+ },
+ "results": {
+ "items": {
+ "$ref": "#/$defs/OpportunityRow"
+ },
+ "title": "Results",
+ "type": "array"
+ },
+ "warning": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Set when paging stopped early; the results so far are still valid.",
+ "title": "Warning"
+ }
+}Output schema / requiredAdded value: +[
+ "results",
+ "has_more"
+]Output schema / titlePrevious value: -"search_grantsDictOutput"New value: +"SearchResult"search_jobs7 fields changedInput schema / properties / naics / descriptionPrevious value: -"Up to 10 six-digit NAICS codes, comma-separated, e.g. '236220' or '541511,541512'. Unknown codes are ignored."New value: +"Up to 10 six-digit NAICS codes, comma-separated, e.g. '236220' or '541511,541512'. A record matches on its own codes (matched_naics says which). Unknown codes are ignored."Input schema / properties / posted_within_days / descriptionPrevious value: -"Only jobs posted in the last N days, 1 to 30."New value: +"Only jobs posted within the last N days, 1 to 30 (default 30)."Output schema / $defsAdded value: +{
+ "Naics": {
+ "properties": {
+ "code": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Code"
+ },
+ "title": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Title"
+ }
+ },
+ "title": "Naics",
+ "type": "object"
+ },
+ "OpportunityRow": {
+ "description": "One search result. Jobs fill title, agency (the employer), state, city, posted_at and url only.",
+ "properties": {
+ "agency": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Agency"
+ },
+ "agency_id": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "The agency's MatchAwards id.",
+ "title": "Agency Id"
+ },
+ "ai_matched_naics": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Only when you filtered by naics: requested codes this contract notice matched only because MatchAwards' AI suggested them, not its own codes. Call such a match AI-suggested.",
+ "title": "Ai Matched Naics"
+ },
+ "city": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "City"
+ },
+ "id": {
+ "description": "Pass to get_opportunity for the description and contacts.",
+ "title": "Id",
+ "type": "string"
+ },
+ "matched_naics": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Only when you filtered by naics: the requested codes this record carries: its own code (in naics) or, for a grant or job, another code of its program or occupation.",
+ "title": "Matched Naics"
+ },
+ "naics": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/Naics"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "On state notices (type state) the naics code itself is AI-assigned."
+ },
+ "no_fixed_deadline": {
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "true: the deadline is a placeholder date.",
+ "title": "No Fixed Deadline"
+ },
+ "office": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Office"
+ },
+ "posted_at": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Date, YYYY-MM-DD.",
+ "title": "Posted At"
+ },
+ "response_deadline": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Date, YYYY-MM-DD; null if none.",
+ "title": "Response Deadline"
+ },
+ "sam_url": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "The SAM.gov notice (federal only). Show it as a markdown link.",
+ "title": "Sam Url"
+ },
+ "set_aside": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Set Aside"
+ },
+ "solicitation_number": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Solicitation Number"
+ },
+ "state": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "State"
+ },
+ "title": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Title"
+ },
+ "type": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "federal, state, grant or job.",
+ "title": "Type"
+ },
+ "url": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "The posting on matchawards.com. Show it as a markdown link.",
+ "title": "Url"
+ }
+ },
+ "required": [
+ "id"
+ ],
+ "title": "OpportunityRow",
+ "type": "object"
+ }
+}Output schema / additionalPropertiesRemoved value: -trueOutput schema / propertiesAdded value: +{
+ "as_of": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "When the API generated the results (ISO time).",
+ "title": "As Of"
+ },
+ "has_more": {
+ "description": "true: call again with cursor=next_cursor and the same filters.",
+ "title": "Has More",
+ "type": "boolean"
+ },
+ "next_cursor": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Next Cursor"
+ },
+ "note": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Note"
+ },
+ "results": {
+ "items": {
+ "$ref": "#/$defs/OpportunityRow"
+ },
+ "title": "Results",
+ "type": "array"
+ },
+ "warning": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Set when paging stopped early; the results so far are still valid.",
+ "title": "Warning"
+ }
+}Output schema / requiredAdded value: +[
+ "results",
+ "has_more"
+]Output schema / titlePrevious value: -"search_jobsDictOutput"New value: +"SearchResult"show_resultsfind_contactsget_opportunitysearch_by_naicssearch_contractssearch_grantssearch_jobsSearch U.S. federal contract opportunities (RFPs, bids, awards) from SAM.gov official data.
Government contract search and federal procurement data: SAM.gov opportunities + USASpending awards.
Pay-per-result SAM.gov contracts, SEC EDGAR filings, USAspending awards and GLEIF LEI lookups.
See who wins US federal contracts and grants (USAspending.gov). $0.02/call via x402.
Add one secure layer between your agents and this server.