SAM.gov contract opportunities and entity lookup (BYOK) plus USASpending federal award data.
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.
Average 4.4/5 across 7 of 7 tools scored.
Each tool has a clearly distinct purpose: two are code/name resolvers, two are searchers (awards vs opportunities), one fetches award details, one looks up entities, and one aggregates spending. No two tools overlap in function, and descriptions reinforce the boundaries.
All tool names follow a consistent snake_case verb_noun pattern (find_agency, find_naics, get_award, lookup_entity, search_awards, search_opportunities, spending_by_category). The use of 'lookup' instead of 'find' is a minor stylistic variation but does not break the overall pattern.
Seven tools is well-scoped for a federal market intelligence server, covering the essential operations of entity resolution, searching, detail retrieval, and aggregation without unnecessary bloat. Each tool earns its place.
The tool set provides strong coverage of the federal market research workflow: resolving agencies and NAICS codes, searching opportunities and awards, retrieving award details, vetting entities, and aggregating spending. The only notable gap is the absence of a dedicated 'get_opportunity' tool to mirror 'get_award' for retrieving full opportunity details.
find_agencyFind a federal agency by nameAResolve a federal agency name fragment to its official awarding-agency names (toptier and subtier) as USAspending knows them — use before search_awards or spending_by_category when unsure of the exact agency name. Keyless.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Agency name fragment, e.g. "navy" or "DISA" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior, lowering the burden. The description adds useful context: it resolves to official toptier and subtier names and notes 'Keyless', which is beyond the annotations. It does not mention failure behavior or return format, but this is not critical for a read-only lookup.
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 core action and outcome, and every clause earns its place. 'Keyless' is a useful standalone note without padding.
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 one-parameter read-only tool with strong annotations, the description covers purpose, usage context, and output scope (toptier/subtier names). It lacks a return format but the description sufficiently conveys what the agent needs to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes the query parameter with examples ('navy' or 'DISA'). The description's phrase 'federal agency name fragment' adds minimal new meaning over the schema, so baseline 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 uses a specific verb ('Resolve') and resource ('federal agency name fragment' to 'official awarding-agency names'), clearly stating what the tool does. It distinguishes from siblings by referencing search_awards and spending_by_category and by focusing on agency-name resolution, unlike find_naics or get_award.
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: 'use before search_awards or spending_by_category when unsure of the exact agency name.' This gives direct guidance on context and names specific alternative tools, making the usage unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_naicsFind NAICS codesAResolve an industry description to NAICS codes (or look up what a NAICS code means). Use before search_opportunities/search_awards to get the right code. Keyless.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Industry description ("cybersecurity services") or a NAICS code ("541512") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety. The description adds the keyless nature and clarifies the input can be either a description or a code, which is useful beyond annotations. It does not contradict 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 entire description is three short sentences, front-loaded with the purpose, followed by usage context, and ending with 'Keyless.' Every sentence adds meaningful information with no fluff.
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?
The tool is simple with one parameter and no output schema. The description covers purpose, usage, and keyless access, giving the agent everything needed to select and invoke it correctly. It also contextualizes within the sibling toolset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the query parameter description already explains the accepted inputs: 'Industry description ("cybersecurity services") or a NAICS code ("541512")'. The tool description repeats this without additional semantics, so baseline 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 uses specific verbs 'Resolve' and 'look up' with the resource 'NAICS codes', clearly stating the tool's dual functionality. It also distinguishes from siblings by positioning it as a preparatory step before search_opportunities/search_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 explicitly states when to use the tool: 'Use before search_opportunities/search_awards to get the right code.' This provides clear context and names the relevant sibling tools, giving the agent actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_awardGet one federal award (USASpending)AGet full detail for one federal award from USAspending.gov by its generated award id (from search_awards results, e.g. "CONT_AWD_...") — description, obligations, period of performance, awarding/funding agencies, recipient, and place of performance. Keyless.
| Name | Required | Description | Default |
|---|---|---|---|
| award_id | Yes | generated_internal_id / generated_unique_award_id from search_awards |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context beyond annotations: it discloses the 'Keyless' nature (no authentication required) and enumerates the specific content areas returned (description, obligations, period of performance, agencies, recipient, place of performance). This gives the agent a clear expectation of what the call will yield.
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 concise sentences. The first sentence front-loads the core purpose and input source. The second provides a compact list of returned content. No fluff or redundant information; every phrase 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?
For a simple get-by-id tool, the description is fully sufficient: it identifies the input (award_id from search_awards), explains the output content areas, and notes the keyless access. Annotations cover safety and idempotency, and there is no output schema that would require further return-value explanation. The description is complete for the agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter description in the schema already defines 'award_id' as 'generated_internal_id / generated_unique_award_id from search_awards'. The tool description adds an example format ('CONT_AWD_...') and explicitly ties it to the search_awards results, enriching the semantics beyond the schema's description. This helps the agent understand what value to supply.
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 function: 'Get full detail for one federal award from USAspending.gov by its generated award id'. This specific verb+resource+scope distinguishes it from sibling tools like search_awards (which lists awards) and spending_by_category (which aggregates). The mention of 'one federal award' and the id source from search_awards further clarifies its distinct role.
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 this tool: it operates on an award id obtained from search_awards results, with an example format. This implies a sequential workflow (search first, then get details). While it does not explicitly state 'when not to use' or list alternatives, the prerequisite and single-record focus serve as adequate usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_entityLook up a SAM.gov registered entityALook up a federal contractor registration in SAM.gov by Unique Entity ID (UEI) or legal business name: registration status, CAGE code, physical address, business types (SDVOSB, 8(a), HUBZone, etc.), and NAICS codes. Call this to vet a teaming partner, check a competitor, or confirm an entity is award-eligible. Public registration sections only.
| Name | Required | Description | Default |
|---|---|---|---|
| uei | No | 12-character Unique Entity ID | |
| name | No | Legal business name (partial match allowed) — used when no UEI given | |
| sam_api_key | No | Optional: your own free SAM.gov API key (from sam.gov → Account Details). With it you spend your own 1,000/day quota and skip the shared budget. Can also be sent once as the X-Sam-Api-Key header on the MCP connection. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint, destructiveHint) already cover the safety profile, and the description adds useful context with 'Public registration sections only,' clarifying that data is limited to public SAM.gov sections. It also lists the specific returned fields, giving the agent a clearer behavioral picture without contradicting 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 tightly packed sentences cover purpose, input methods, returned data, use cases, and a limitation. Every phrase earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 3 optional parameters and no output schema, the description effectively compensates by listing return fields (registration status, CAGE, address, business types, NAICS) and providing explicit use cases. The 'Public registration sections only' qualifier adds necessary constraint. The tool's scope is small and the description covers it sufficiently.
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 well-documented. The description echoes the two lookup modes (UEI or name) and adds what results will contain, but it doesn't convey anything beyond the schema's existing parameter descriptions. It adds minimal value over structured fields.
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 a specific verb ('Look up') and resource ('a federal contractor registration in SAM.gov'), and distinguishes itself from siblings by focusing on entity registration data rather than awards, opportunities, agencies, or NAICS codes. The explicit mention of search methods (UEI or legal business name) and returned fields leaves 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?
Explicitly states when to use the tool: 'Call this to vet a teaming partner, check a competitor, or confirm an entity is award-eligible.' This provides clear scenarios with positive guidance, though it does not explicitly mention when not to use it or name alternative tools for exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_awardsSearch federal contract awards (USASpending)ASearch actual federal contract awards on USAspending.gov — who won what, from which agency, for how much. Filter by keywords, NAICS, PSC, recipient name, agency, date range, and award amount. Keyless and unlimited. Call this for competitive intelligence ("who holds contracts in this space"), incumbent research, or agency spending patterns.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 10) | |
| end_date | No | YYYY-MM-DD (default: today) | |
| keywords | No | Keyword filters | |
| psc_codes | No | ||
| recipient | No | Recipient (contractor) name search | |
| max_amount | No | ||
| min_amount | No | ||
| start_date | No | YYYY-MM-DD (default: 1 year ago) | |
| agency_name | No | Awarding toptier agency name, e.g. "Department of Defense" | |
| naics_codes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds 'Keyless and unlimited,' which provides behavioral insight beyond the read-only annotation. It also describes the data source and the type of output ('who won what, from which agency, for how much'). While the annotations already cover safety, the description enriches the understanding of the tool's access and data characteristics without contradicting any 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 two sentences long, front-loaded with the core function in the first clause, and includes essential use cases in the second sentence. Every word contributes to understanding the tool, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers the tool's purpose and use cases, it lacks information about pagination, result ordering, and exact handling of multiple filters. With no output schema, it does not fully describe the return format beyond a high-level summary. For a 10-parameter tool, some additional details on response structure would improve completeness, though the annotations partially offset this.
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 has 60% description coverage, and the description lists filter categories ('keywords, NAICS, PSC, recipient name, agency, date range, and award amount') which gives some meaning beyond the raw schema. However, it does not explain syntax or defaults for parameters like max_amount/min_amount, and with moderate schema coverage, it adds value but not comprehensive compensation.
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 'Search actual federal contract awards on USAspending.gov — who won what, from which agency, for how much.' This clearly defines the specific verb (search), resource (federal contract awards), and platform (USAspending.gov). It also distinguishes from siblings like search_opportunities (which targets opportunities) and get_award (which fetches a single award) by focusing on the broader contract award search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete use cases: 'Call this for competitive intelligence... incumbent research, or agency spending patterns.' This gives clear context for when to use the tool. It does not explicitly name alternatives or state when not to use it, but the use cases effectively imply the intended scenarios relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_opportunitiesSearch SAM.gov contract opportunitiesASearch active federal contract opportunities on SAM.gov: solicitations, presolicitations, sources sought, RFIs, and award notices — filterable by keywords, NAICS, set-aside (SDVOSB, 8(a), HUBZone, WOSB, small business), notice type, agency, and posted-date range (max 1 year). Call this when the user wants to find federal bidding opportunities or market intelligence on what agencies are buying. Uses a shared daily budget unless the caller supplies their own free SAM.gov key.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 10) | |
| agency | No | Department/agency name filter | |
| keywords | No | Free-text keywords, e.g. "CMMC compliance" | |
| posted_to | No | YYYY-MM-DD (default: today) | |
| set_aside | No | Set-aside codes: SDVOSBC/SDVOSBS (SDVOSB), VSA/VSS (VOSB), SBA/SBP (small business), 8A/8AN, HZC/HZS (HUBZone), WOSB/EDWOSB | |
| naics_codes | No | NAICS codes, e.g. ["541512"] | |
| notice_type | No | o=solicitation, p=presolicitation, r=sources sought, k=combined synopsis, g=surplus, s=special notice, a=award notice, i=intent to bundle, u=J&A | |
| posted_from | No | YYYY-MM-DD (default: 90 days ago; SAM allows at most a 1-year window) | |
| sam_api_key | No | Optional: your own free SAM.gov API key (from sam.gov → Account Details). With it you spend your own 1,000/day quota and skip the shared budget. Can also be sent once as the X-Sam-Api-Key header on the MCP connection. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the safe read-only/idempotent annotations, the description discloses a shared daily budget limitation and the option to supply a personal SAM.gov API key to use one's own quota. It also notes the max 1-year posting-date window. These are meaningful behavioral traits that help set expectations around rate limits and key requirements.
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 carry the full message: the first states the verb, resource, and filter scope; the second gives usage guidance and quota/key context. No filler words; every clause 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 9 parameters and no output schema, the description effectively covers the tool's purpose, filterable aspects, intended use case, date constraints, and quota behavior. The absence of return-format details is acceptable since no output schema exists and the core usage is clear.
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% with clear per-parameter descriptions, including enum mappings for set_aside and notice_type. The description summarizes the filterable dimensions but does not add semantic details beyond what the schema already provides. It earns the baseline 3 for a well-documented 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 starts with 'Search active federal contract opportunities on SAM.gov' and enumerates specific notice types (solicitations, presolicitations, sources sought, RFIs, award notices) and filter dimensions (keywords, NAICS, set-aside, notice type, agency, posted-date range). This clearly distinguishes it from siblings like search_awards and get_award, which focus on award records rather than opportunities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Call this when the user wants to find federal bidding opportunities or market intelligence on what agencies are buying.' This provides clear usage context. However, it does not explicitly name alternatives or when-not-to-use conditions, so it falls short of the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
spending_by_categoryFederal spending rollupsAAggregate federal contract spending by NAICS, PSC, recipient, or awarding agency over a date range, optionally filtered by keywords/NAICS/agency — market sizing in one call ("top contractors in NAICS 541512 last year", "which agencies buy the most cybersecurity"). Keyless.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Top N (default 10) | |
| category | Yes | ||
| end_date | No | YYYY-MM-DD (default: today) | |
| keywords | No | ||
| start_date | No | YYYY-MM-DD (default: 1 year ago) | |
| agency_name | No | ||
| naics_codes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds 'Keyless' and 'over a date range' scoping, which are useful contextual details beyond the annotations. It does not describe return format or pagination, but the safety profile is well-covered by 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 a single, front-loaded sentence with an em-dash separator and inline examples. Every word contributes meaning, with no filler or redundant restatement.
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?
The description provides the essential context for grouping and filtering, with examples that clarify typical use cases. Since there is no output schema, a note on return structure would improve completeness, but the tool's aggregate nature is sufficiently conveyed.
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 only 43%, but the description compensates by explicitly mapping category to grouping dimensions (NAICS, PSC, recipient, awarding agency) and mentioning keywords/NAICS/agency filters. It also implies date range and top-N behavior through examples, though it doesn't explain each parameter in detail.
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 a specific verb 'Aggregate' and resource 'federal contract spending' with clear grouping dimensions (NAICS, PSC, recipient, awarding agency), making its function distinct. The examples ('top contractors in NAICS 541512 last year') further solidify its purpose, differentiating it from sibling search tools like search_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 phrase 'market sizing in one call' and the illustrative queries clearly signal when to use this tool for aggregate analysis rather than searching individual awards. It does not explicitly name alternative tools or state when not to use it, but the context is strongly implied.
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.
No comments yet. Be the first to start the discussion!