The GovToolsPro MCP server provides decision-support tools for federal contractors throughout the contracting lifecycle, offering synthesized insights rather than raw data.
Credit & Subscription Check (balance): View your current credit balance, total credits used, and subscription status (free).
Solicitation Retrieval (get_solicitation): Fetch structured SAM.gov data by notice ID or solicitation number, including title, NAICS, PSC, set-aside, place of performance, deadlines, contacts, and attachment links.
Go/No-Go Scoring (score_go_no_go): Score a solicitation 0–100 against your company profile with hard-blocker detection (CMMC gaps, set-aside ineligibility, geographic constraints) and a GO / NO-GO / REVIEW recommendation.
Incumbent Identification (find_incumbents): Identify the current incumbent via USAspending and FPDS, including award value, competition signals, and anticipated next-award date.
Teaming Partner Search (find_partners_near): Find nearby businesses matching a capability keyword near a place of performance, ranked by proximity with contact details.
Recompete Prediction (predict_recompete): Discover expiring contracts filtered by NAICS, PSC, state, and value, enriched with option-exercise and competition signals.
Navy NECO Lookup (lookup_neco_data): Parse Navy NECO solicitations into structured fields (title, NSN/line items, deadline, buyer contact, document links).
Labor Rate Benchmarking (lookup_labor_rates): Get GSA CALC ceiling rates and BLS OEWS wages with a +55% government wrap estimate for a NAICS or labor category.
Award Pattern Analysis (analyze_award_patterns): Analyze award-size distribution, competition mix, bid intensity, contract vehicles, and pricing types. Costs 3 credits.
Market Intelligence (analyze_market): Get a full market snapshot for a NAICS — 5-year spending trends, top contractors, HHI concentration, set-aside mix, geographic distribution, and contract vehicle usage. Costs 5 credits.
An MCP server that gives Claude (and any MCP client) workflow tools for federal contractors — not raw data access, but decisions: go/no-go scoring, incumbent intelligence, teaming-partner search, recompete prediction, Navy NECO lookup, SAM.gov solicitation retrieval, and market intelligence (labor rates, award patterns, market analysis).
It wraps the live GovToolsPro API. You bring an API key; the server proxies your calls.
Tool | Cost | What it does |
| free | Credit balance + subscription status. |
| free | Notice ID (or solicitation number) → structured SAM.gov fields (NAICS, PSC, set-aside, place of performance, deadline, contacts, attachment links). The workflow entry point. |
| free | Score a solicitation GO / NO-GO (0–100) against your company profile, with hard-blocker detection (CMMC, geographic, set-aside). |
| free | Identify the current incumbent via USAspending + FPDS, with competition signals and anticipated next-award date. |
| free | Rank nearby teaming partners / subcontractors by proximity for a place of performance. |
| free | Discover expiring contracts (recompete opportunities) by NAICS/PSC/state/value, enriched with option-exercise signals. |
| free | Parse a Navy NECO (neco.navy.mil) solicitation into structured fields. No other govcon MCP has this. |
| free | Benchmark federal labor rates for a NAICS / labor category — GSA CALC awarded ceiling rates + BLS OEWS wages with a government wrap estimate. |
| 3 credits | How contracts in a NAICS are awarded: award-size distribution, competition mix, bid intensity, contract vehicles, pricing types. |
| 5 credits | Market-intelligence snapshot for a NAICS: 5-year spend trend, industry size, top contractors + HHI concentration, set-aside mix, geography, contract vehicles. |
Every tool returns decision-support output with a disclaimer — verify against the official solicitation before relying on results. Credits are drawn from the shared GovToolsPro pool (extension + API + connector all bill the same balance); free tools never deduct.
Related MCP server: TenderAI
Add to your MCP client config (Claude Desktop, Claude Code, Cursor, Cline, Zed, …):
{
"mcpServers": {
"govtoolspro": {
"command": "npx",
"args": ["-y", "govtoolspro-mcp-server"],
"env": { "GOVTOOLSPRO_API_KEY": "gtp_live_..." }
}
}
}Create a key in the GovToolsPro extension → Profile → API Keys tab (format gtp_live_... / gtp_test_...).
Prefer not to run anything locally? GovToolsPro is also a hosted remote MCP server you can add to Claude as a connector — no install, no API key, sign in with your GovToolsPro account.
Remote MCP URL: https://mcp.govtoolspro.com/api/mcp
In Claude: Settings → Connectors → Add custom connector, paste the URL, and leave the OAuth fields blank (the server self-registers via Dynamic Client Registration).
You'll be sent to auth.govtoolspro.com to sign in; Claude then connects over OAuth 2.1. Toggle the connector on in a conversation to use its tools.
The same 10 tools are available over the connector, billed against the same shared credit balance as the extension and the stdio package.
Env var | Required | Default |
| yes | — |
| no |
|
npm install
npm run build
# end-to-end stdio smoke test against the live API
GOVTOOLSPRO_API_KEY=gtp_test_... npm run smokeTo point a client at your local build:
{
"command": "node",
"args": ["/absolute/path/to/govtoolspro-mcp-server/dist/index.js"],
"env": { "GOVTOOLSPRO_API_KEY": "gtp_test_..." }
}Workflow MCP, not a data wrapper. Competing govcon MCPs return raw SAM.gov/FPDS JSON; these tools return synthesized decisions.
CUI safety. The API rejects content with CUI / FOUO / Distribution-Statement markings; those rejections surface to the client as clear errors. Do not submit controlled content.
No warranty. Output is decision support only — not legal, contractual, or award-outcome advice.
Symptom | Cause / fix |
| Three tools are metered ( |
Connector keeps asking you to sign in / 401 | The remote connector requires OAuth — complete sign-in at |
| That NAICS has no federal activity in the window — you are not charged. Try a broader NAICS or fewer filters. |
CUI rejection error | The API rejects content marked CUI / FOUO / Distribution-Statement. Remove controlled content and retry. |
| Use the 32-char notice ID from the |
Invalid API key (stdio) | Ensure |
MIT © Michael Smyth
Analyze how contracts in a NAICS are typically awarded: award-size distribution, competition mix (full & open / limited / sole-source), bid intensity (single-bid rate, expected bidders), contract vehicles, and pricing types. From public USAspending + FPDS data. Costs 3 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| naicsCode | Yes | NAICS code (required). | |
| pscCode | No | Optional PSC code to narrow the analysis. | |
| years | No | Lookback in years (default ~3). | |
| state | No | Optional 2-letter place-of-performance state filter. |
| Name | Required | Description |
|---|---|---|
| awardSizeDistribution | No | |
| competition | No | |
| bidStatistics | No | |
| contractVehicles | No | |
| pricingTypes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint. Description adds value by stating data source (USAspending + FPDS) and cost (3 credits), which are beyond the annotations and provide useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the purpose and outputs, then state data source and cost. No filler or redundancy; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (4 params, output schema exists), description covers purpose, outputs, data source, and cost. Could mention data recency or limitations, but overall sufficient.
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?
Input schema provides full descriptions for all 4 parameters (100% coverage). Description does not add parameter-specific semantics beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool analyzes award patterns for contracts in a NAICS, listing specific outputs (award-size distribution, competition mix, etc.). It distinguishes from siblings like analyze_market by narrowing to award patterns and listing typical metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies use when award pattern analysis is needed, but does not explicitly state when to use or avoid this tool versus siblings like analyze_market or find_incumbents. No alternative guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full market-intelligence snapshot for a NAICS: 5-year federal spending trend, industry size (Census), top contractors with market share + HHI concentration, set-aside distribution, geographic distribution, and contract-vehicle usage. From public USAspending + Census data. Costs 5 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| naicsCode | Yes | NAICS code (required). | |
| pscCode | No | Optional PSC code for sharper competitor filtering. | |
| setAside | No | Optional set-aside context. |
| Name | Required | Description |
|---|---|---|
| spendingTrend | No | |
| industryContext | No | |
| federalSharePct | No | |
| topContractors | No | |
| concentration | No | |
| setAsideDistribution | No | |
| geographicDistribution | No | |
| contractVehicles | No | |
| recentLargeAwards | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent, and open-world behavior. The description adds value by disclosing the data sources (USAspending + Census) and the credit cost (5 credits). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with key content. Every sentence earns its place, providing a clear overview without unnecessary verbosity.
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 the tool's complexity and the presence of an output schema, the description sufficiently covers the tool's scope. It lists major output categories and capabilities, making it complete for agent decision-making.
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. The description does not add further meaning to the parameters beyond what the schema provides; it lists output components but does not clarify input semantics like NAICS format or PSC 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's purpose: providing a full market-intelligence snapshot for a NAICS code. It lists specific components (federal spending trend, industry size, top contractors, etc.) and distinguishes from siblings like analyze_award_patterns, which focuses on awards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through its output scope (market snapshot, not awards), but it does not explicitly state when to use this tool vs alternatives like analyze_award_patterns or find_incumbents. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the current GovToolsPro credit balance and subscription status for the authenticated account. Free — exercises auth end-to-end. The extension and the API draw from the same shared credit pool.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| balance | Yes | Current total credit balance. |
| subscriptionCredits | No | Credits from the active subscription. |
| topupCredits | No | Credits purchased as one-off top-ups. |
| totalUsed | No | Lifetime credits consumed. |
| totalPurchased | No | Lifetime credits purchased. |
| subscription | No | Active subscription, or null if none. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent, open-world. The description adds value by stating it's free, that it exercises authentication end-to-end, and that the extension and API share the same credit pool. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that are front-loaded with the main purpose. No unnecessary words. Every sentence provides useful context.
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 the tool has zero parameters, annotations covering safety traits, and an output schema (not shown but exists), the description is complete. It explains what is returned and additional context about auth and credit pool.
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?
No parameters are defined (schema coverage 100% by default). With zero parameters, the baseline is 4. The description doesn't need to add parameter info.
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 returns the credit balance and subscription status for the authenticated account. The verb 'Return' and resource 'credit balance and subscription status' are specific. Sibling tools like find_incumbents serve different purposes, so no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is provided. It mentions exercising auth end-to-end and being free, but doesn't explicitly tell an agent when to select this tool over alternatives or in what context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identify the likely current incumbent(s) for a solicitation using public USAspending + FPDS award data. Returns the primary incumbent (name, award value, period of performance), FPDS competition signals (offers received, set-aside, sole-source flags), and an anticipated next-award start date. Deterministic, free. FPDS failures degrade gracefully (USAspending half stays intact).
| Name | Required | Description | Default |
|---|---|---|---|
| solicitation | Yes | Solicitation context. naicsCode is REQUIRED. Optional: pscCode, agency, subAgency, office, placeOfPerformance, title, responseDeadline. | |
| years | No | USAspending lookback in fiscal years (default 5, max 10). | |
| limit | No | Max USAspending contracts (default 50, max 100). | |
| fpdsMaxResults | No | Max FPDS contracts (default 50, max 100). | |
| anticipatedStartDate | No | ISO date overriding the responseDeadline-based anticipated-start calculation. |
| Name | Required | Description |
|---|---|---|
| primaryIncumbent | No | |
| otherIncumbents | No | |
| usaspendingResults | No | |
| fpdsResults | No | |
| fpdsError | No | |
| anticipatedStartDate | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it notes the tool is deterministic, free, and handles FPDS failures gracefully (USAspending data remains intact). This is useful for an agent understanding side effects and reliability.
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 concise, front-loaded with the core purpose and data sources, and every sentence provides valuable information. No extraneous 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?
Given the tool's complexity (multiple data sources, multiple outputs), the description covers purpose, outputs, data sources, and failure behavior. An output schema exists for return values, so additional detail is not critical. Lacks explicit prerequisites beyond NAICS (already in schema), but that is acceptable.
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 parameters are fully documented. The description does not add additional parameter-level information beyond what the schema provides, but the schema is sufficient. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool identifies likely current incumbent(s) for a solicitation using specified public data sources. It specifies the output (incumbent name, award value, period of performance, etc.), distinguishing it from sibling tools like get_solicitation or predict_recompete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding incumbents but does not explicitly state when to use this tool versus alternatives. It does not mention when not to use it or provide comparisons with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find potential teaming partners / subcontractors near a solicitation's place of performance via Google Places. Given a capability keyword and a geocodable address, returns nearby businesses ranked by proximity, enriched (top results) with phone and website. Deterministic, free. Verify capabilities, certifications, and eligibility independently before relying on results.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Industry/capability term, e.g. 'IT support', 'electrical contractor', 'janitorial services'. | |
| address | Yes | Place of performance — any geocodable string, e.g. 'Arlington, VA' or a full street address. | |
| radius | No | Search radius in miles (default 25, max 100). |
| Name | Required | Description |
|---|---|---|
| businesses | Yes | |
| placeOfPerformance | No | |
| totalResults | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses deterministic, free nature, enrichment of top results, and the need for independent verification beyond annotations which already mark it as read-only and idempotent.
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 focused sentences: first defines purpose and inputs, second details output and cautions. No unnecessary 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?
Covers essential aspects (inputs, output format, limitations, verification need), and output schema handles return values, so no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are fully described in the schema, and the description adds minimal extra meaning beyond restating the keyword and address roles.
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?
Clearly states it finds potential teaming partners/subcontractors near a solicitation's place of performance, distinguishing it from sibling tools like find_incumbents.
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 ties usage to solicitation context and provides caution to verify independently, but does not discuss when to avoid or compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a single SAM.gov solicitation's structured fields by notice ID (or, best-effort, by solicitation number). Returns title, solicitation number, type, NAICS, PSC, set-aside, place of performance, response deadline (with timezone), points of contact, description, and attachment download links. Deterministic, free — pulls from SAM.gov's public opportunity records. This is the entry point for a workflow: feed the returned fields into score_go_no_go, find_incumbents, or find_partners_near.
| Name | Required | Description | Default |
|---|---|---|---|
| noticeId | No | 32-character hex SAM.gov notice ID (the ID in a sam.gov/opp/<id>/view URL). Primary, most reliable input. | |
| solicitationNumber | No | Solicitation number (e.g. '140P6026Q0003'). Best-effort fallback — resolved via SAM.gov search; provide noticeId when you have it. | |
| includeAttachments | No | Include attachment download links (default true). Set false to skip the extra lookup. |
| Name | Required | Description |
|---|---|---|
| noticeId | Yes | |
| title | Yes | |
| solicitationNumber | No | |
| type | No | |
| typeLabel | No | |
| naicsCode | No | |
| naicsCodes | No | |
| pscCode | No | |
| setAside | No | |
| responseDeadline | No | |
| responseTimeZone | No | |
| placeOfPerformance | No | |
| pointOfContact | No | |
| postedDate | No | |
| modifiedDate | No | |
| archiveDate | No | |
| cancelled | No | |
| archived | No | |
| description | No | |
| link | No | |
| attachments | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint. The description adds 'Deterministic, free — pulls from SAM.gov's public opportunity records,' reinforcing idempotency and clarifying the public source. No contradictions.
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 concise sentences, front-loaded with the core action and returning fields. No wasteful wording; every sentence adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With complete schema coverage, clear annotations, and a detailed output schema (not shown but known), the description fully covers the tool's purpose, parameters, and workflow integration. No gaps remain.
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%. The description adds value by explaining the primary/favored status of noticeId and the best-effort fallback of solicitationNumber, beyond the schema descriptions.
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 retrieves a single SAM.gov solicitation by notice ID or solicitation number, listing returned fields. It distinguishes itself from siblings by positioning as the workflow entry point and naming downstream tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (as the entry point for a workflow feeding into score_go_no_go, find_incumbents, or find_partners_near). Does not contrast with all siblings like balance or lookup_neco_data, but provides sufficient context for typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Benchmark federal labor rates for a NAICS code and/or a specific labor category. Returns GSA CALC awarded ceiling rates (min/median/max by category) plus BLS OEWS wage data with a +55% government wrap (loaded hourly) estimate. Free. Public GSA + BLS data — verify allowable rates against the RFP.
| Name | Required | Description | Default |
|---|---|---|---|
| naicsCode | No | NAICS code — maps to GSA labor categories + BLS SOC occupations. | |
| laborCategory | No | Specific labor category for a direct GSA search, e.g. 'program manager', 'software engineer'. |
| Name | Required | Description |
|---|---|---|
| gsaRates | Yes | |
| blsWages | Yes | |
| summary | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint=false, and idempotentHint=true. The description adds valuable behavioral details: it specifies the output includes 'GSA CALC awarded ceiling rates (min/median/max by category) plus BLS OEWS wage data with a +55% government wrap estimate,' and notes the data is free and public. No contradictions.
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 four sentences long, with the primary purpose in the first sentence. Every sentence adds value: what it does, what it returns, that it is free/public, and a usage tip. No extraneous 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?
Given the output schema exists, the description does not need to detail the return structure fully. It covers the key output components and data sources. It lacks mention of data freshness or limitations, but for a public-data lookup tool, this is acceptable.
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% with both parameters having descriptions. The tool description does not add significant new meaning beyond the schema; it only restates that the tool works with NAICS code and/or labor category. Thus, the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Benchmark federal labor rates for a NAICS code and/or a specific labor category,' which clearly specifies the verb (benchmark/lookup) and resource (federal labor rates). The tool name and description align, and the sibling tools (e.g., analyze_award_patterns, predict_recompete) are distinct, so differentiation is inherent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context: it is for benchmarking federal labor rates using GSA CALC and BLS data, and advises to 'verify allowable rates against the RFP.' Although it does not explicitly state when not to use or name alternatives, the context is clear and sufficient given the absence of closely related sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch and parse a Navy NECO (Navy Electronic Commerce Online) solicitation page into structured data — solicitation number, title, response deadline, NSN/line items, buyer contact, set-aside, and document links. Deterministic scrape of the public neco.navy.mil site, free. No other govcon MCP exposes NECO data. Pass the full NECO URL when you have it (most reliable); solicitationNumber alone is best-effort.
| Name | Required | Description | Default |
|---|---|---|---|
| necoUrl | No | Full NECO solicitation URL (https://www.neco.navy.mil/...). Primary, most robust input. | |
| solicitationNumber | No | Navy solicitation number. Best-effort — the main NECO page may require an hkey to resolve. | |
| hkey | No | Optional NECO hkey — improves solicitationNumber resolution. |
| Name | Required | Description |
|---|---|---|
| requestedUrl | Yes | |
| data | No | |
| summary | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds context: 'Deterministic scrape of the public neco.navy.mil site, free.' This extra detail about safety and cost is valuable 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?
The description is three sentences with no waste. It front-loads the action and key fields, then provides usage guidance and differentiation. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but mentioned), the description need not detail return values. It covers input guidance, behavioral context (deterministic, free), and unique value proposition. With annotations and full schema coverage, no gaps remain.
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. The description adds critical meaning: 'Primary, most robust input' for necoUrl, 'Best-effort' for solicitationNumber, and explains how hkey 'improves solicitationNumber resolution.' This exceeds the schema's descriptions.
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 verbs ('Fetch and parse') and clearly identifies the resource ('Navy NECO solicitation page'). It lists the structured fields extracted and explicitly distinguishes itself from siblings by stating 'No other govcon MCP exposes NECO data.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Pass the full NECO URL when you have it (most reliable); solicitationNumber alone is best-effort.' It also mentions that the tool is deterministic and free. While it doesn't explicitly list when not to use alternatives, the sibling differentiation is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover federal contracts expiring within a window (recompete opportunities) via public USAspending data, optionally enriched with procurement-history signals (all-options-exercised, offers received, set-aside, competition type). Filter by NAICS, PSC, state, value, and keywords. Returns contracts with days-until-expiration and urgency. Deterministic, free. Expiration/option signals reflect reported data and may lag.
| Name | Required | Description | Default |
|---|---|---|---|
| filters | No | All optional. Narrow the recompete search. | |
| page | No | Page number (default 1). | |
| limit | No | Results per page (default 25, max 100). | |
| sortOrder | No | Sort by End Date (default 'desc'). | |
| enrich | No | Enrich top results with procurement history (default true). | |
| enrichCount | No | How many to enrich (default 10, max 25). |
| Name | Required | Description |
|---|---|---|
| contracts | Yes | |
| totalCount | Yes | |
| hasMore | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. Description adds 'Deterministic, free' and 'Expiration/option signals reflect reported data and may lag,' providing extra context about behavior and data freshness beyond 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?
Few sentences, front-loaded with main purpose, then details. No redundant phrases. Every sentence serves a 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?
Covers source (USAspending), filter options, enrichment, return fields (days-until-expiration, urgency), and behavioral notes (deterministic, free, data lag). Completes the picture for a retrieval tool with nested filters and enrichment.
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?
Input schema has 100% description coverage, so the schema already explains all parameters. Description summarizes filter types but adds no significant new meaning 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?
Clearly states the tool discovers expiring federal contracts as recompete opportunities, with specific filtering and enrichment options. Distinguishes from sibling tools like find_incumbents or get_solicitation by focusing on recompete detection.
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?
Implies usage when needing recompete opportunities, but no explicit guidance on when not to use or how it compares to siblings. Lacks exclusionary criteria or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score a federal solicitation as GO / NO-GO (0-100) against a company profile. Detects hard blockers (CMMC certification gaps, geographic/OEM constraints, set-aside ineligibility), scores NAICS match, past performance, and capability fit, and returns a recommendation with red flags and reasons. Deterministic decision-support — no AI, free. Pass the analyzed solicitation documents (from your extension or an analyze-solicitation step) plus your company profile.
| Name | Required | Description | Default |
|---|---|---|---|
| documentAnalyses | Yes | Analyzed solicitation documents (required, at least one). Each item is the structured analysis of a solicitation document (summary, classification with naicsCode/setAside, valueAndScope with placeOfPerformance, etc.). | |
| profile | No | Company profile to score against: company (legalName, address.state), industryCodes.primaryNaics, businessTypes (smallBusiness, sdvosb, ...), capabilities (coreCompetencies, cmmcStatus.level). | |
| solicitationData | No | Optional extra solicitation context, e.g. { responseDeadline }. | |
| incumbentData | No | Optional incumbent context, e.g. { primaryIncumbent } from find_incumbents. |
| Name | Required | Description |
|---|---|---|
| score | Yes | 0-100 fit score. |
| recommendation | Yes | GO / NO-GO / REVIEW. |
| blockers | No | |
| reasons | No | |
| categoryScores | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with annotations (readOnlyHint, idempotentHint) and adds value by explaining deterministic behaviour, detection logic for hard blockers, and output structure. No contradictions. However, it does not detail all possible edge cases or limitations.
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 concise with three sentences that front-load the purpose, then detail the logic and inputs. Every sentence adds necessary information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (four parameters, nested objects, output schema present), the description adequately explains inputs and high-level output. It could mention that the output includes a numeric score and recommendations, but the output schema covers 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% and each parameter has detailed descriptions in the schema. The tool description does not add new information beyond summarizing the inputs; therefore it meets the baseline for high schema coverage without extra param semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states that the tool scores a federal solicitation as GO/NO-GO (0-100) against a company profile, and lists specific capabilities like detecting hard blockers, scoring NAICS match, etc. This clearly distinguishes it from sibling tools such as find_incumbents or predict_recompete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool by stating it requires analyzed solicitation documents and a company profile. It mentions it is deterministic and free, but does not explicitly exclude alternatives or provide when-not-to-use guidance against siblings.
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.
v0.1.4analyze_award_patternsanalyze_marketlookup_labor_ratesv0.1.1balancefind_incumbentsfind_partners_nearget_solicitationlookup_neco_datapredict_recompetescore_go_no_goScored across 10 tools
Each tool has a clearly distinct purpose: market analysis, award pattern analysis, incumbent identification, partner finding, solicitation retrieval, labor rate lookup, NECO data lookup, recompete prediction, go/no-go scoring, and credit balance check. No two tools overlap in functionality.
Most tools follow a consistent verb_noun pattern (e.g., analyze_market, find_incumbents, get_solicitation, lookup_labor_rates). The only outlier is 'balance', which is a noun and could be renamed to 'get_balance' or 'check_balance' for consistency.
10 tools is an appropriate number for a government contracting intelligence server. Each tool covers a specific analytical or data retrieval function without unnecessary duplication, and the scope is well-defined.
The tool set covers the main aspects of government contracting analysis: market overview, specific solicitation details, partner finding, labor rates, recompete opportunities, and decision support. A minor gap is the lack of a tool to search or list solicitations by keyword, as get_solicitation requires a known ID.
Federal+SLED govcon MCP: SAM, USASpending, recompete, hearings, policy intel, search. Private AI.
GovCon Intel MCP — Compound tools that chain SAM.gov, USAspending,
MCP access to the U.S. federal procurement graph: contracts, opportunities, entities, and more.
MCP server giving Claude AI access to 22+ NYC public-record databases for real estate due diligence
