Federal sales intelligence: expiring-contract triggers, agency spend intel, deal qualification.
Scored across 5 tools
Each tool has a distinct job in the federal sales workflow: agency spend profile, expiring contracts, incumbent history, discovery questions, and deal qualification. There is mild overlap between find_expiring_contracts and incumbent_lookup (both surface end dates/incumbents) and between generate_discovery_questions and qualify_opportunity (both produce question sets), but the descriptions and required inputs clearly separate them.
All names are readable snake_case, but the convention is mixed: some are verb-first actions (find_expiring_contracts, generate_discovery_questions, qualify_opportunity) while others are noun-first resources (agency_spend_profile, incumbent_lookup). Consistent style throughout, inconsistent pattern.
Five tools is well-scoped for a focused federal-sales intelligence server, and each maps to a clear stage of the sales motion (prospect, research, prep, qualify). No redundant or filler tools.
The surface covers the core public-sector selling lifecycle: agency buying patterns, recompete triggers, incumbent displacement, meeting prep, and MEDDPICC qualification. The main gap is the absence of a tool to search specific federal opportunities/awards by keyword or solicitation (e.g. SAM.gov-style lookup), which agents would otherwise have to work around.
Use this to answer "what does this agency actually buy, and from whom?" before a first call: total contract obligations, 3-year trend, top 10 vendors, and top 10 NAICS categories for the latest fiscal year with published data. Good queries name one agency, e.g. agency="HHS". Figures come from a daily snapshot of USAspending (latest published fiscal year plus a 3-year trend); the fiscal year and freshness are stated in the response. Federal only. Read the coverage caveats — in-progress fiscal years are partial, and intel-agency spend is never published.
| Name | Required | Description | Default |
|---|---|---|---|
| agency | Yes | Federal agency name, acronym, or code — e.g. "HHS", "Department of Veterans Affairs", "075". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses the data source (daily USAspending snapshot), the time scope (latest published FY plus 3-year trend), that freshness/FY are echoed in the response, federal-only coverage, and two real limitations (partial in-progress FYs, intel-agency spend never published).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the purpose and the question it answers, then the payload, then caveats. Dense but every sentence contributes; slightly long, with the caveat clause compressed into one run-on 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?
There is no output schema, so the description must describe returns — and it does: obligations, trend, top vendors, top NAICS, plus the FY/freshness echoed back. Combined with the coverage caveats, an agent has everything needed to call and interpret this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single required `agency` param, including format examples (name, acronym, code), so the schema already does the heavy lifting. The description reinforces this with "Good queries name one agency, e.g. agency='HHS'" but adds no new syntax or constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (profile a federal agency's contract spending) and enumerates the exact payload: total obligations, 3-year trend, top 10 vendors, top 10 NAICS categories for the latest published FY. This is clearly distinguishable from siblings like find_expiring_contracts or incumbent_lookup without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly frames the use case ("before a first call", answering "what does this agency actually buy, and from whom?") and gives query-shaping guidance ("name one agency, e.g. agency='HHS'"). It does not name alternatives or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when prospecting or prepping a federal account and you want sales triggers: contracts at an agency that end soon, with the incumbent vendor, dollar values, and contracting office. Expiring contracts mean upcoming recompetes — the best time to displace an incumbent. Good queries name one agency and optionally a NAICS code, e.g. agency="DHS", naics_code="541512", window_days=90. Federal only (no state/local). Every response includes data-freshness and coverage caveats — read them; no data ≠ no spend.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max contracts to return (top by obligated amount). Default 15. | |
| agency | Yes | Federal agency name, acronym, or code — e.g. "DHS", "Department of Defense", "070". Federal only; SLED is out of scope. | |
| naics_code | No | Optional NAICS code to narrow by category, e.g. "541512" (computer systems design). | |
| window_days | No | How far ahead to look for contract end dates, in days from today. Default 90, max 365. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses the tool's focus on federal contracts, the meaning of expiring contracts (upcoming recompetes), and that responses include data-freshness and coverage caveats. This adds value beyond the schema, though it does not elaborate on authorization 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?
The description is a single concise paragraph that front-loads the purpose, then gives usage guidance and an example. No word is wasted; every sentence serves a distinct informative purpose.
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?
No output schema exists, so the description must cover return fields. It mentions incumbent vendor, dollar values, contracting office, and data-freshness caveats. This is sufficient for a tool of moderate complexity, though it could include pagination or sort order details.
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 baseline is 3. The description enhances schema info with a concrete example (agency='DHS', naics_code='541512', window_days=90) and explains the 'limit' parameter sorts by obligated amount. This adds practical clarity for parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds expiring federal contracts for sales triggers, specifying the return fields (incumbent vendor, dollar values, contracting office). This distinguishes it from siblings like agency_spend_profile or incumbent_lookup, which have different purposes.
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 explicitly says 'Use this when prospecting or prepping a federal account and you want sales triggers' and provides example queries. It also notes 'Federal only (no state/local)'. However, it does not explicitly state when not to use or provide alternatives, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when prepping a meeting with a federal agency: it returns discovery questions tuned to public-sector selling (fiscal-year timing, contract vehicles, FedRAMP/ATO, incumbents), grounded in the agency's live spending data where possible — each data-backed question cites the number that motivated it with a source URL. Good queries name the agency, what you sell, and the meeting type, e.g. agency="DHS", product_category="zero-trust network security", meeting_context="first_call". Add naics_code to surface expiring-contract questions.
| Name | Required | Description | Default |
|---|---|---|---|
| agency | Yes | Federal agency the meeting is with — name, acronym, or code, e.g. "DHS". | |
| naics_code | No | Optional NAICS code for your category — adds questions about specific expiring contracts. | |
| meeting_context | No | What kind of meeting you are prepping for. | first_call |
| product_category | Yes | What you sell, in plain words — e.g. "data analytics platform", "zero-trust network security". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that questions are data-backed with URL sources, tuned to public-sector specifics (fiscal-year timing, contract vehicles, FedRAMP/ATO, incumbents). Does not mention auth or rate limits, but is transparent about core 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 sentences, no wasted words, includes example and context. Front-loaded with key usage guidance, then details. Highly efficient.
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?
No output schema, but description explains return format (discovery questions with data-backed citations). Covers all 4 parameters, usage context, and public-sector nuances. For a tool of this complexity, it is quite complete, though could mention if multiple questions are returned.
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 baseline is 3. Description adds value by providing a concrete usage example and explaining the role of naics_code for expiring-contract questions. Explains all four parameters purposefully beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates discovery questions for public-sector selling, with specific verb 'returns discovery questions' and resource. It distinguishes from sibling tools like agency_spend_profile by focusing on question generation rather than data retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use this when prepping a meeting with a federal agency' and provides an example query. Lacks explicit 'when not to use', but context implies not for non-public sector. Good guidance on optional parameters like naics_code.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this to answer "who am I displacing and when?": a vendor name (plus optional agency scope) returns their current and recent awards with values and end dates, flagging awards that end within 12 months as displacement windows. Good queries use the vendor's registered name or a distinctive fragment, e.g. vendor="Booz Allen", agency="DHS". Federal only. Zero results ≠ no presence — check the caveats for name-matching tips.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max awards to return (largest first). Default 15. | |
| agency | No | Optional federal agency to scope the lookup, e.g. "DHS". Omit to search government-wide. | |
| vendor | Yes | Vendor/incumbent name as registered in federal awards, e.g. "Booz Allen Hamilton", "CACI". FPDS matches it as a phrase — shorter fragments match more. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses behavior: returns current/recent awards with values and end dates, flags those ending within 12 months, notes federal-only scope, and addresses name-matching caveats with zero results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences front-load the purpose, provide usage guidance, and address edge cases, with no wasted words.
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?
Despite no output schema, the description fully explains return values (awards with values, end dates, displacement flags) and handles caveats, making the tool self-contained for an agent.
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 100% schema coverage, the description adds substantial meaning beyond the schema by providing example queries, explaining name matching, and illustrating expected input patterns like vendor='Booz Allen', agency='DHS'.
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 specific verb 'Look up' and resource 'incumbent vendor's federal contracts', and clearly distinguishes from siblings by focusing on displacement windows and answering 'who am I displacing and when?'
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 explicitly states when to use ('to answer who am I displacing and when?') and provides query examples with vendor and agency, but does not explicitly mention when not to use or compare with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this to pressure-test a federal deal: pass what you know per MEDDPICC dimension (leave unknowns empty) and get back an evidence-scored scorecard adapted for public sector — budget authority instead of generic economic buyer, procurement vehicle as the paper process — with gap-closing questions and public-record evidence pulled automatically (name the incumbent_vendor and their real awards/end dates at the agency get attached). Scores measure evidence specificity, not truth; the response says what verified evidence looks like for each dimension.
| Name | Required | Description | Default |
|---|---|---|---|
| agency | Yes | Federal agency the deal is at — name, acronym, or code, e.g. "DHS". | |
| deal_facts | No | What you know so far, one field per MEDDPICC dimension. Omit entirely (or leave fields empty) for pure-discovery scoring — gaps are the output. | |
| incumbent_vendor | No | Competitor/incumbent vendor name if known — their real awards at this agency get pulled as evidence. | |
| product_category | Yes | What you are selling, e.g. "SIEM platform". | |
| estimated_value_usd | No | Rough deal size in USD, if known. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It discloses that scores measure 'evidence specificity, not truth', and that public-record evidence for incumbent_vendor is automatically attached. It also mentions the output includes gap-closing questions. However, it does not mention error handling, rate limits, or behavior when required fields are missing beyond schema validation.
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 dense paragraph that packs a lot of information. While it is front-loaded with the core purpose, it could be broken into shorter sentences or bullet points for easier parsing. Some phrases are verbose (e.g., 'public-record evidence pulled automatically').
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 there is no output schema, the description adequately explains the return format: an evidence-scored scorecard with gap-closing questions and public-record evidence. It also explains the scoring philosophy. However, it does not specify the structure of the scorecard or how results are presented.
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 each parameter has a description, but the tool description adds meaningful context beyond the schema. For example, it explains that 'economic_buyer' is 'who has budget/obligation authority' adapting to public sector. The nested 'deal_facts' object is explained in terms of MEDDPICC dimensions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'pressure-test a federal deal' using MEDDPICC dimensions. It distinguishes itself from sibling tools by specifying the federal/public-sector adaptation and the output format (scorecard with gap-closing questions). No other sibling appears to do the same specialized scoring.
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 explains when to use: 'pass what you know per MEDDPICC dimension (leave unknowns empty) and get back an evidence-scored scorecard'. It implies that this is for qualification, not discovery, but does not explicitly state when to use alternatives like 'generate_discovery_questions' or 'incumbent_lookup'. The context is clear, but explicit exclusions are missing.
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.
agency_spend_profilefind_expiring_contractsgenerate_discovery_questionsincumbent_lookupqualify_opportunityFederal contract intelligence: $7T+ awards, SAM.gov opps, pWin verdicts, recompetes, protests.
Government contract search and federal procurement data: SAM.gov opportunities + USASpending awards.
Federal contracts, FDA recalls, business registrations, Amazon products — B2B intel.
Federal+SLED govcon MCP: SAM, USASpending, recompete, hearings, policy intel, search. Private AI.
Add one secure layer between your agents and this server.
