Skip to main content
Glama

Search Contracts & RFPs

search_procurement
Read-onlyIdempotent

CONTRACTS & PROCUREMENT — Search government contracts, RFPs, RFIs, BAAs, and solicitations from SAM.gov. Better than searching SAM.gov directly — includes semantic search and NAICS industry filtering to exclude commodity noise. Use when user wants: contracts, RFPs, procurement, bids, government work. Examples: "IT consulting services", "construction management", "cybersecurity contracts". BATCH MODE (paid): pass a queries[] array of 2-5 variations instead of query to run them in parallel, dedupe, and return all unique results in one call — this replaces the former batch_search_procurement tool. When sam_filters.place_of_performance_state (alias: pop_state, accepted in both single and batch mode) is set, the response includes a placeOfPerformance field reporting how many results are confirmed performed in that state (matched), how many have no confirmed location and are shown demoted with a caveat (unknownServed, excluded instead when user_context.location_strict is true), and how many were excluded for being tagged to a different, parseable state (otherStateExcluded; geography we could not parse into any state, such as a bare address or ZIP code, counts as unknownServed instead); a batch call sums these across every sub-query. Paid plans show new listings the day they open; the free plan reaches the same listings after 10 days. Counts toward your monthly searches. A batch counts as 1 call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax results (default: 25)
queryNoNatural language search query. Provide either query (single search) or queries (batch mode) — exactly one.
sinceNoStateless alternative to posted_within_days/new_within_days: ISO 8601 instant. Only opportunities ingested at/after this instant. Store the previous response newSince.newest and pass it here to manage your own watermark.
cursorNoPagination cursor from previous response
offsetNoBatch mode only: number of merged results to skip for pagination (default 0). Ignored in single-query mode.
sourceNoFilter to a specific source/domain, e.g. "sam.gov" or an agency source domain.
statusNoFilter by status
compactNoReturn compact results (default: true). Set to false for full details.
queriesNoBATCH MODE (paid, replaces batch_search_procurement): array of 2-5 search queries to run in parallel, dedupe, and merge. Example for IT services: ["IT services contract", "software development federal", "technology consulting government", "computer services procurement"]. When set, query is ignored and the batch response params (detail_level, max_results, offset, max_response_tokens) apply.
max_resultsNoBatch mode only: maximum merged results to return (default 10). Ignored in single-query mode (use limit).
min_qualityNoMinimum quality threshold (default: medium)
sam_filtersNoSAM.gov specific filters
detail_levelNoBatch mode only: controls response verbosity (minimal/compact [default]/full). Ignored in single-query mode.
organizationNoFilter by contracting agency
user_contextNoUser context for better filtering
new_within_daysNoBackwards-compatible alias for posted_within_days. Only opportunities WE ADDED (ingested) in the last N days for recurring/delta checks ("what is new since my last check"). Additive to all other filters. In queryless browse mode without a single source, the recency window is sampled across sources round-robin by ingest recency so one bulk harvester cannot own the digest; each source remains newest first. The response includes newSince and windowCoverage: sourcesSampled counts distinct sources returned by the grouped provider query before MCP quality, judge, recency-withhold, and page filters; it is absent when no grouped sample was available, including when sampling was not attempted, and 0 means the grouped query succeeded but returned no sourced rows; sourcesServed counts distinct sources delivered on this page. windowCoverage.order is "recency" for the queryless browse digest or "relevance" when a query is present. windowIncomplete/incompleteReason is separate from ceilingTruncated, which is true only when the 2,000-row ceiling excluded records; ceilingTruncated and hardCeiling are present only when order is "recency" and are omitted entirely under "relevance" (query mode never walks past a single bounded fetch, so no ceiling logic runs). Not the opportunity posted date or deadline.
procurement_typeNoFilter by industry. professional_services = consulting/engineering/R&D (NAICS 54xxxx). it_services = software/IT (NAICS 5415xx). construction = building (NAICS 23xxxx). manufacturing = production (NAICS 31-33xxxx).
posted_within_daysNoPreferred alias for new_within_days: only opportunities WE ADDED (ingested) in the last N days. In queryless browse mode without a single source, the recency window is sampled across sources round-robin by ingest recency so one bulk harvester cannot own the digest; each source remains newest first. In windowCoverage, sourcesSampled counts distinct sources returned by the grouped provider query before MCP quality, judge, recency-withhold, and page filters; it is absent when no grouped sample was available, including when sampling was not attempted, and 0 means the grouped query succeeded but returned no sourced rows; sourcesServed counts distinct sources delivered on this page. windowCoverage.order is "recency" for the queryless browse digest or "relevance" when a query is present. windowIncomplete/incompleteReason is separate from ceilingTruncated, which is true only when the 2,000-row ceiling excluded records; ceilingTruncated and hardCeiling are present only when order is "recency" and are omitted entirely under "relevance" (query mode never walks past a single bounded fetch, so no ceiling logic runs). Uses the same ingest freshness field as newSince/recurring checks; not the opportunity posted date or deadline. If both posted_within_days and new_within_days are supplied, posted_within_days wins.
max_response_tokensNoBatch mode only: token budget for the response (default 4000). Server auto-caps results to fit. Ignored in single-query mode.
deadline_within_daysNoOnly opportunities closing within N days

TDQS

A4.4/5.0
Behavior5/5

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

Even with readOnlyHint, idempotentHint, and destructiveHint annotations already present, the description adds substantial operational context: free vs. paid data lag, monthly search counting, batch deduplication and summing, ignored psc_code, and detailed placeOfPerformance demotion/exclusion behavior. This is exactly the kind of non-obvious behavior an agent needs and is not visible in 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.

Conciseness3/5

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

The description front-loads purpose and examples effectively, but it is very long and dense, repeating some details that already exist in the schema, such as batch-mode behavior and alias precedence. Each sentence carries some information, but the wall-of-text format and duplication make it harder to scan. It would benefit from paragraph breaks and tighter editing.

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

Completeness4/5

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

For a tool with 20 parameters, nested objects, and no output schema, the description is unusually thorough: it covers plan-tier data freshness, batch semantics, ignored filters, geographic matching caveats, and search-count impact. It does not provide a concise high-level statement of the overall result shape or pagination flow, which would be useful given the absent output schema, so it is not a 5.

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

Parameters4/5

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

The input schema already documents all 20 parameters, so the baseline is 3. The description adds real value beyond the schema by explaining batch-mode usage and its replacement of batch_search_procurement, clarifying the pop_state/place_of_performance_state alias semantics, and detailing how the state filter affects response fields. It does not deeply re-explain every parameter, but its additional semantics are meaningful.

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

Purpose5/5

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

The description is explicit and specific: it names the resource (government contracts, RFPs, RFIs, BAAs, solicitations from SAM.gov), the operation (search), and typical user intents with concrete example queries. It distinguishes itself from grants-focused siblings by leading with 'CONTRACTS & PROCUREMENT' and by explaining that its batch mode replaces the former batch_search_procurement tool.

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

Usage Guidelines4/5

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

The description clearly states 'Use when user wants: contracts, RFPs, procurement, bids, government work' and gives examples, which is strong guidance. It also explains when to use batch mode via queries[]. However, it does not explicitly contrast this tool with grants-focused siblings or state when NOT to use it, so it falls just short of full when/when-not coverage.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation4/5

Most tools have clear distinct purposes. Some overlap exists (e.g., search_grantsplus and search_foundations both return foundations, but descriptions clarify the distinction). Also batch_ variants are comprehensive versions of the standard searches. Overall, agents can differentiate well.

Naming Consistency4/5

Tool names predominantly follow verb_noun pattern in snake_case (e.g., search_grantsplus, get_opportunity, list_saved_searches). Minor deviation with 'whats_new' (no underscore) and 'check_connection' (different verb form). Otherwise consistent.

Tool Count4/5

26 tools is slightly above the typical 3-15 range but still reasonable for a comprehensive funding landscape server covering grants, procurement, foundations, saved searches, account management, and utilities. Each tool serves a clear purpose.

Completeness4/5

The tool surface covers core search, detail retrieval, saved search management, account information, and feedback. Missing are profile management or direct payment modification tools (only links provided). Minor gaps but overall complete for the domain.

Resources