SAM.gov Opportunities MCP server

search_opportunities

Read-only

Search active SAM.gov federal contract opportunities by keyword, agency, NAICS/PSC, set-aside, state, and deadline to surface relevant notices newest first.

Instructions

Search active SAM.gov federal contract opportunities. Returns notices newest first, with agency, deadline, NAICS, PSC, set-aside, place of performance, primary contact and SAM.gov link (award notices also include the awardee and amount).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "search_opportunities"
  }
}

Input Schema

Name	Required	Description	Default
`detail`	No	'compact' (key fields) or 'full' (description, all contacts, attachment links).	compact
`states`	No	Two-letter place-of-performance states, e.g. ['CO', 'UT'].
`agencies`	No	Agency or department names, e.g. ['Department of Veterans Affairs', 'Army'].
`keywords`	No	Words to search in title and description, e.g. 'roof repair'.
`psc_codes`	No	Product/Service codes or prefixes, e.g. ['DA01'], ['65'], ['Z2'].
`set_asides`	No	Set-aside codes: SBA (total small business), SBP (partial), 8A, 8AN (8(a) sole source), HZC (HUBZone), SDVOSBC (service-disabled veteran), WOSB, EDWOSB, VSA (VA veteran-owned), ISBEE, IEE, LAS, or NONE. Friendly names like 'HUBZone' or 'SDVOSB' also work.
`max_results`	No	Maximum notices to return. Each costs $0.003.
`naics_codes`	No	NAICS codes or prefixes, e.g. ['541512'] or ['2362', '238'].
`notice_types`	No	Only these notice types. Default: all.
`posted_since`	No	Only notices posted or updated on or after this date (YYYY-MM-DD). Default: last 7 days.
`deadline_within_days`	No	Only notices whose response deadline is within this many days.
`open_for_response_only`	No	Only notices with a future response deadline (drops awards and notices without a deadline).

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 6, 2026

TDQS

B3.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, openWorld, idempotent=false and non-destructive, so the safety profile is covered. The description adds genuine behavioral context — results are ordered newest first, and award notices carry awardee and amount fields — but says nothing about cost per result ($0.003, exposed only in a parameter description), result caps, or pagination.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero filler, with the resource and the return shape front-loaded. The parenthetical about award notices is the only nuance and it earns its space.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 12 optional parameters, full schema coverage, annotations and an output schema, the description only needs to frame search behavior — and it omits the default 7-day posted_since window and the cost implication of max_results, both of which materially affect how an agent calls it. It is adequate but leaves the default-scope surprise unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, including enum values, examples and the per-result cost note, so the schema carries all parameter meaning. The description adds no filter semantics of its own, which is the correct baseline-3 outcome when the schema is this complete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb+resource ("Search active SAM.gov federal contract opportunities") and enumerates what comes back, so the agent knows exactly what class of operation this is. It does not explicitly contrast itself with the sibling get_opportunity, so sibling differentiation is only implied by "search" vs "get".

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use / when-not-to-use guidance in the description at all. Nothing tells the agent to prefer this for discovery and get_opportunity for a single known notice, nor that an unqualified call defaults to the last 7 days of postings (that detail lives only in the schema).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server