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
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/5 across 4 of 4 tools scored.
Each tool targets a distinct aspect of government contracts: agency_spending for spending summaries, contract_detail for single records, search_contracts for searching, and trending_opportunities for trends. No functional overlap.
All tool names use lowercase snake_case with a clear pattern: descriptive compound names (agency_spending, contract_detail, search_contracts, trending_opportunities). No mixing of conventions.
Four tools cover the core needs of querying government contracts: search, detail, spending summary, and trends. The count is appropriate for a focused read-only data service.
The tool set covers essential query operations for government contracts data. A minor gap might be the lack of advanced filtering or awardee-specific tools, but the core functions are well represented.
Available Tools
4 toolsagency_spendingAInspect
Spending summary for a federal 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 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?
With no annotations, the description discloses key behaviors: live data from USASpending.gov, payment requirement after free allowance (402 error), need for Solana memo and re-call with payment_tx, and an Authorization header bypass. It does not cover rate limits or error handling for missing agencies, but is fairly transparent overall.
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 front-loaded with the core purpose, then adds necessary payment details. It could be slightly trimmed, but every sentence provides value. It is well-structured and readable.
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 (parameters, payment flow, output schema exists), the description covers the main purpose, data source, and payment mechanics. It mentions the breakdowns in output, so return values are hinted. It lacks details on data freshness or limitations, but is fairly complete for a summary tool with output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add significant meaning beyond the schema; it reiterates the payment flow context but does not elaborate on parameter usage or constraints.
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 provides a spending summary for a federal agency, breaking down contract dollars by NAICS sector and top awardees, computed live from USASpending.gov. It distinguishes itself from sibling tools by emphasizing it's a summary of the full federal record, not a local table.
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 does not explicitly guide when to use this tool versus siblings. It implies it's a summary (vs. detailed contracts from contract_detail or search_contracts), but lacks direct "use this when..." or "alternatives" statements. The payment instructions are provided, but not selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
contract_detailAInspect
Fetch the full record for a single contract by its solicitation number (for awards, the USASpending generated_internal_id). 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?
No annotations are provided, so the description carries the full burden. It adds context about the solicitation number meaning for awards, but does not disclose behavioral traits like error handling, rate limits, or data freshness.
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, front-loaded with the main action, and contains no unnecessary words. 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 tool has only one parameter and an output schema is present, the description is adequate. It explains the input and the free nature. It could mention error handling for missing contracts, but overall it's fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single parameter with a description. The description adds value by explaining that the solicitation_number is 'the natural key from a search_contracts result', which helps the agent understand where to obtain the value.
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 ('Fetch'), the resource ('full record for a single contract'), and the key identifier ('solicitation number'). It also distinguishes from siblings like 'search_contracts' by focusing on a single record.
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 mentions it's free, which is a usage guideline, but does not explicitly state when to use this tool vs alternatives or when not to use it. The sibling names provide some context, but the description itself lacks explicit guidance.
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 — both open opportunities / solicitations (SAM.gov) and awarded contracts (USASpending/FPDS) — from one aggregated, deduplicated dataset. Results are sorted newest-first.
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?
No annotations provided, so description bears full burden. It discloses the paywall behavior, free allowance, payment_tx parameter, and sorting order. Does not mention pagination or result format, but output schema exists. Overall, key behavioral traits are well explained.
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 paragraphs: first states purpose and sorting, second details payment model. Front-loaded with no extraneous information. Every sentence is necessary and useful.
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 complexity (11 parameters, output schema exists), description covers core purpose, payment model, and key parameters. It does not detail pagination or search behavior beyond the schema, but output schema handles return values. Sibling relationships are not explained, but purpose clarity compensates.
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% (all parameters have descriptions). Description adds value by explaining how agent_id scopes the free allowance and how payment_tx is used after a 402 response, providing context 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?
Description clearly states 'Search U.S. federal government contracts' covering both open solicitations and awarded contracts from an aggregated, deduplicated dataset, specifying sources (SAM.gov, USASpending/FPDS) and sorting order. This distinguishes it from sibling tools like agency_spending (spending totals) and contract_detail (specific 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?
Describes when to use the tool (search contracts across both types) and provides clear context for usage including daily free allowance, payment instructions, and agent_id for scoping. Does not explicitly exclude alternatives or compare to siblings, but the description is sufficient for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trending_opportunitiesAInspect
Which sectors are seeing the most new federal solicitations right now.
Buckets the opportunities posted in the last days by NAICS sector and
ranks them by new-solicitation volume (with the agencies driving each).
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 discloses the payment mechanism (paid query after free allowance, 402 workflow with payment_tx). It also mentions the daily free allowance and optional Authorization header. However, it does not disclose behavior like caching, rate limits beyond the daily allowance, or data freshness.
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 front-loaded with the tool's purpose in the first sentence, followed by necessary payment details. It is reasonably concise with two clear paragraphs, though the payment explanation is somewhat detailed. No unnecessary 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?
Given the presence of an output schema and 4 parameters, the description covers the output (buckets by sector, ranked by volume with agencies) and the payment flow. It lacks mention of error conditions or pagination, but the output schema likely handles that. Adequate for a moderate-complexity tool.
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 already described. The description adds context by referencing 'last days' and 'NAICS sector' in the purpose statement, which aligns with the days and naics parameters. It does not add substantial new meaning beyond the schema for agent_id and payment_tx, but reinforces the overall workflow.
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 which sectors have the most new federal solicitations, bucketed by NAICS sector and ranked by volume. It uses specific verbs ('buckets', 'ranks') and resources ('sectors', 'new federal solicitations'), making it distinct from sibling tools like contract_detail or search_contracts.
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 does not provide guidance on when to use this tool versus alternatives like agency_spending or search_contracts. It only explains the payment flow for usage after a 402 response, but no when/when-not information is given.
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!