Government Contracts MCP
Server Details
Government contract search and federal procurement data: SAM.gov opportunities + USASpending awards.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- FoundryNet/gov-contracts-mcp
- GitHub Stars
- 0
- Server Listing
- Government Contracts MCP
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 7 of 7 tools scored. Lowest: 3.7/5.
Each tool targets a distinct aspect of federal procurement: spending analysis, contract search, detailed records, daily briefs, trend analysis, and protocol info. No two tools have overlapping purposes, so an agent can clearly distinguish them.
All tool names use lowercase with underscores and follow a descriptive noun_verb or noun_noun pattern (e.g., agency_spending, search_contracts, daily_brief). The convention is uniform and predictable.
With 7 tools, the server covers the core operations for government contract analysis without being too sparse or overwhelming. Each tool serves a clear function, and the count is well-scoped for the domain.
The tool set covers search, detail retrieval, spending analysis, trend detection, and daily briefs, providing a complete surface for federal procurement data consumption. No obvious gaps such as missing CRUD operations, as the domain is read-only analysis.
Available Tools
7 toolsagency_spendingAInspect
Analyze U.S. federal government spending for an agency — contract dollars broken down by NAICS sector and the top awardees, computed live from USASpending.gov for the requested fiscal year (the full federal procurement record, not just the local table).
PAID: $0.01 USDC per query after the daily free allowance. On a 402, pay the returned Solana memo and re-call with the SAME arguments plus payment_tx=. An Authorization: Bearer fnet_ key bypasses it.
| Name | Required | Description | Default |
|---|---|---|---|
| agency | Yes | awarding toptier agency name as USASpending labels it (e.g. "Department of Defense", "Department of Commerce"). | |
| agent_id | No | stable id for your agent (scopes the free-tier counter). | |
| payment_tx | No | Solana tx signature, when re-calling after a 402. | |
| fiscal_year | No | U.S. federal FY (e.g. 2026). Defaults to the current FY. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that data is computed live from USASpending.gov, that there is a payment of $0.01 USDC per query after a free allowance, and how to handle 402 errors with a payment transaction. This provides essential behavioral context beyond what annotations (none) offer.
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 the purpose and data source in the first paragraph and payment details in the second. It is front-loaded and contains 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?
Given that an output schema exists (so return values are documented elsewhere), the description adequately covers the tool's behavior, data source, payment flow, and error handling. It does not cover potential failures like invalid agency names, but overall it is 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?
The input schema covers all parameters with descriptions, so the description does not add new meaning beyond what the schema already provides. The description mentions 'fiscal year' generally, but no additional semantics per parameter.
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: analyzing U.S. federal government spending for an agency, broken down by NAICS sector and top awardees, computed live from USASpending.gov. It distinguishes itself from siblings by focusing on high-level agency spending breakdowns rather than individual contract details.
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 agency-level spending analysis but does not explicitly state when to use this tool versus alternatives like contract_detail or search_contracts. No exclusions or 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.
brief_summaryAInspect
Get the top 5 signals from today's brief as structured JSON — a cheap sample of the full daily_brief. Returns the day's highest-priority items (no prose) so an agent can decide whether to buy the full brief.
PAID: $0.50 USDC (vs the full daily_brief price). Defaults to today (UTC). On a 402, pay the returned Solana memo and re-call with the SAME args plus payment_tx=. An Authorization: Bearer fnet_ key bypasses payment.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | brief date YYYY-MM-DD (default today, UTC). | |
| agent_id | No | stable id for your agent (scopes the free-tier counter). | |
| payment_tx | No | Solana tx signature, when re-calling after a 402. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It discloses that this is a paid operation, returns structured JSON (no prose), defaults to UTC today, requires payment memo on 402, and has an Authorization header bypass. All behavioral traits are transparent.
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 well-structured with key purpose first, then cost, defaults, and error handling. It is mostly concise, though a few operational details could be tightened slightly without losing clarity.
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 3 optional parameters, good schema descriptions, an output schema, and sibling tools listed, the description covers the main use case, cost, error handling, and auth. It is sufficiently complete for an agent to use 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. The description adds value by explaining the payment flow ('payment_tx' for re-call after 402) and the purpose of 'agent_id' (free-tier counter scoping). This goes 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 verb 'Get', the resource 'top 5 signals from today's brief', and the output format 'structured JSON'. It explicitly distinguishes from sibling 'daily_brief' by being a cheaper sample.
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 this tool (decide whether to buy full brief), notes the cost ($0.50 USDC vs full brief), defaults, and provides explicit instructions for payment failures (402) and auth bypass. It gives clear context for using vs. alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
contract_detailAInspect
Get the full record for one U.S. federal government contract or solicitation by its solicitation number (for awards, the USASpending generated_internal_id) — including agency, NAICS code, value, and response deadline from SAM.gov / USASpending. FREE — no payment and no free-tier consumption.
| Name | Required | Description | Default |
|---|---|---|---|
| solicitation_number | Yes | the natural key from a search_contracts result. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the free nature and lists returned fields, adding value beyond the schema. It does not mention rate limits, data freshness, or side effects, but for a simple read operation this is sufficient.
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-loaded with purpose, no redundant words. The second sentence adds important cost context. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with one parameter and an output schema, the description fully explains what the tool does, what it returns, and usage context. 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?
The schema description for the single parameter is minimal ('the natural key from a search_contracts result'), but the tool description adds meaningful context by clarifying it is the solicitation number or USASpending generated_internal_id. With 100% schema coverage, the description adds value 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?
The description clearly states the tool retrieves the full record for a US federal contract or solicitation by its solicitation number, listing key fields (agency, NAICS code, value, response deadline) and sources (SAM.gov/USASpending). It distinguishes itself from sibling tools like search_contracts which returns search results.
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 after obtaining a solicitation number from a search, and explicitly notes it is free with no consumption limits. However, it does not explicitly state when not to use it or enumerate alternatives beyond the implied sibling relationship.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daily_briefAInspect
Get the curated daily U.S. federal government-contracts brief — the day's most significant federal procurement activity from SAM.gov and USASpending in one package: top new solicitations by value, solicitations with approaching response deadlines, major recent awards, and trending NAICS sectors + agencies. Each brief carries a provenance attestation so a buyer can verify it was produced by this server, unaltered.
PAID: $10 USDC per brief. Defaults to today (UTC); a brief expires at the next midnight UTC. On a 402, pay the returned Solana memo and re-call with the SAME args plus payment_tx=. An Authorization: Bearer fnet_ key bypasses payment.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | brief date YYYY-MM-DD (default today, UTC). | |
| agent_id | No | stable id for your agent (scopes the free-tier counter). | |
| payment_tx | No | Solana tx signature, when re-calling after a 402 (x402 rail). | |
| stripe_token | No | Stripe Checkout Session id (cs_…), when re-calling after paying the Stripe payment link (alternative to x402). Can also be supplied via the X-Stripe-Token header. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully handles disclosure. It reveals it is a paid tool, payment methods, and provenance attestation. However, it does not explicitly state it is read-only or idempotent, though implied.
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 well-structured with the main purpose front-loaded, followed by details on payment and flow. Every sentence adds value, though slightly verbose for a simple read tool. Still, it earns its length.
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 and full parameter descriptions, the description covers key aspects: what the brief contains, payment, expiration, and auth bypass. It lacks error handling notes but is sufficient for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the payment flow for payment_tx and stripe_token, and the scope function of agent_id, integrating parameters into the usage narrative.
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 it returns a curated daily brief on U.S. federal procurement activity, listing specific content (solicitations, awards, NAICS sectors). It clearly distinguishes from sibling tools by its unique daily aggregation scope.
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 default behavior (today UTC), expiration at midnight, and payment flow (402 with Solana or Stripe). It does not explicitly contrast with siblings but the purpose makes differentiation clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mint_infoAInspect
Get FoundryNet Data Network info + attestation / provenance details. FREE.
Returns how to record verifiable provenance for your agent's government-contract / federal-procurement analysis (SAM.gov + USASpending), and the sister data servers in the network (brand-intel, patent-intel, financial-signals, weather-intel, cyber-intel, compliance, academic-intel, fact-check, oss-intel, social-intel).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only discloses that the tool is 'FREE' and returns information. It lacks details on authentication, rate limits, output format, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words, front-loading the main purpose. However, the list of servers could be more structured (e.g., bullet points) for clarity.
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 zero parameters and an output schema, the description is fairly complete, explaining what the tool returns. It could be more precise about 'attestation/provenance details,' but overall adequate.
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?
There are no parameters, so schema coverage is 100% vacuously. Baseline for 0 params is 4, and the description adds context about what the tool returns, which is helpful.
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 gets 'FoundryNet Data Network info + attestation / provenance details' and explains what it returns, including specific sister servers. This distinguishes it from sibling tools that focus on contracts/briefs.
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 government-contract/procurement analysis but does not explicitly state when to use this over alternatives. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_contractsAInspect
Search U.S. federal government contracts, solicitations, and awards by agency, value, NAICS code, keyword, state, or status — live from SAM.gov opportunities and USASpending/FPDS awards, newest-first.
Covers federal procurement and government spending across one aggregated, deduplicated dataset of open SAM.gov solicitations and USASpending contract awards.
PAID: $0.01 USDC per query after a daily free allowance. The first calls each day are free; once spent, the tool returns an HTTP-402 body with Solana payment instructions and a memo — pay it, then call again with the SAME arguments plus payment_tx=. Pass agent_id to scope your own free allowance; an Authorization: Bearer fnet_ key bypasses the paywall.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | max rows (1-100, default 25). | |
| naics | No | exact 6-digit NAICS code (e.g. "334517"). | |
| state | No | 2-letter place-of-performance state code (e.g. "TX"). | |
| agency | No | awarding agency name, partial match (e.g. "Defense"). | |
| status | No | one of "active", "closed", "awarded". | |
| keyword | No | free-text matched against title + description (ILIKE). | |
| agent_id | No | stable id for your agent (scopes the free-tier counter). | |
| max_value | No | maximum award amount (USD). | |
| min_value | No | minimum award amount (USD). | |
| payment_tx | No | Solana tx signature, when re-calling after a 402. | |
| posted_after | No | ISO date "YYYY-MM-DD"; only records posted on/after it. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses data freshness (live), ordering (newest-first), deduplication, payment model, and retry logic. It lacks details on pagination behavior beyond the limit parameter and does not mention rate limits or response structure.
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 reasonably concise and front-loaded with the core purpose. It is structured into clear sections (purpose, data sources, payment). Some redundancy exists ('aggregated, deduplicated dataset'), but each sentence adds value.
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 11 parameters, 100% schema coverage, and an output schema, the description is complete enough for an agent to use. It covers data sources, payment, and retry. It could mention pagination beyond the limit parameter, but overall it is adequate.
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 summarizes parameter types in the first sentence but adds minimal additional meaning beyond the schema descriptions. It does not explain defaults or interactions beyond what is in 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?
The description clearly states it searches U.S. federal contracts, solicitations, and awards by various criteria, distinguishing it from siblings like agency_spending or contract_detail. It specifies the data sources (SAM.gov, USASpending) and the aggregated, deduplicated nature, making the purpose explicit and distinct.
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 how to use the tool (by agency, value, NAICS, etc.) and includes payment model instructions (free allowance, HTTP-402, payment_tx, agent_id). However, it does not explicitly contrast with sibling tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trending_opportunitiesAInspect
Analyze which sectors are seeing the most new U.S. federal government
solicitations right now — buckets SAM.gov opportunities posted in the last
days by NAICS code and ranks them by new-solicitation volume, with the
agencies driving each. Surfaces emerging federal procurement demand.
PAID: $0.01 USDC per query after the daily free allowance. On a 402, pay the returned Solana memo and re-call with the SAME arguments plus payment_tx=. An Authorization: Bearer fnet_ key bypasses it.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | look-back window in days (1-365, default 30). | |
| naics | No | optional exact 6-digit NAICS code to restrict to one sector. | |
| agent_id | No | stable id for your agent (scopes the free-tier counter). | |
| payment_tx | No | Solana tx signature, when re-calling after a 402. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: it is a read-only analysis tool, it has a cost model ($0.01 per query after free allowance), and it explains the 402 error recovery flow. This is comprehensive disclosure beyond the schema and 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 concise with no wasted words. The first paragraph front-loads the core functionality, and the second paragraph covers the payment model. Every sentence serves a purpose, making it easy for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, output schema present), the description is complete. It covers the analysis function, parameter roles, payment handling, and error recovery. The presence of an output schema means return values do not need explanation in the description.
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% (each parameter has a description). The description adds meaningful context by explaining how days and naics define the query scope, and how agent_id and payment_tx relate to the free tier and payment flow. This adds value beyond the raw 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 the tool's purpose: analyze sectors with the most new U.S. federal solicitations by NAICS code, ranking by volume. It distinguishes itself from sibling tools (agency_spending, contract_detail, etc.) by focusing on trending opportunities rather than specific contracts or spending.
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 for when to use the tool, such as for identifying emerging procurement demand. It also includes explicit instructions for handling the 402 payment error and free tier. However, it does not explicitly mention when not to use it or compare directly to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.