Skip to main content
Glama

summarize_opportunities

Read-only

Count active SAM.gov notices grouped by agency, sub-tier, office, NAICS, PSC, set-aside, notice type, place-of-performance state, contracting office state, or posted month. Accepts the same filters as search_opportunities, e.g. counts of open solicitations under one NAICS by set-aside, or which agencies posted the most sources sought notices this quarter.

Counts cover active notices in SAM.gov's public daily file, including notices posted in earlier fiscal years that remain active. This is not a complete historical archive; archived notices are not included.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "group_by": "<group_by>"
    },
    "name": "summarize_opportunities"
  }
}

Input Schema

NameRequiredDescriptionDefault
topNoNumber of groups to return, largest first. For posted_month, the most recent months, in month order.
agencyNoText matched against the department, sub-tier, and office names, e.g. Army, Veterans Affairs, NSWC Dahlgren. Field activities post under their own office names, so a command name matches only its headquarters office (NAVSEA matches NAVSEA HQ, not NSWC or NUWC offices).
group_byYesField to group counts by.
keywordsNoWords that must all appear in the title or full description. Put exact phrases in double quotes, e.g. zero trust "cloud migration". Word endings are matched loosely (bridge matches bridges).
posted_toNoLatest posted date, YYYY-MM-DD.
psc_codesNoProduct and service codes or prefixes, e.g. D3 or R425.
deadline_toNoLatest response deadline date, YYYY-MM-DD.
naics_codesNoNAICS codes or prefixes (2 to 6 digits); a prefix such as 5415 matches every code under it.
posted_fromNoEarliest posted date, YYYY-MM-DD.
notice_typesNoCurrent notice types to include. Omit for all types.
office_stateNoTwo-letter state code of the contracting office. Filled in on nearly every notice, but an office's state is not always where the work happens.
deadline_fromNoEarliest response deadline date, YYYY-MM-DD, in the deadline's own time zone.
set_aside_codesNoSAM.gov set-aside codes, e.g. SBA (total small business), 8A, SDVOSBC, WOSB, HZC. NONE means the notice says no set-aside was used.
solicitation_numberNoExact solicitation number.
include_past_deadlinesNoInclude notices whose response deadline has already passed. SAM.gov keeps notices active for a while after the deadline; by default they are left out. Award notices and justifications are always included, even when they list a past deadline, and so are notices with no deadline.
include_earlier_versionsNoInclude earlier versions of amended notices. SAM.gov's file lists every version of a notice as its own row; by default only the latest version of each is included.
place_of_performance_stateNoTwo-letter state code for the place of performance. Most notices leave the place of performance blank, so results also report how many more notices have a contracting office in that state (see office_state).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare read-only, non-destructive, closed-world behavior. The description adds real scope context the annotations don't: counts are limited to active notices in the public daily file, may include notices from earlier fiscal years, and explicitly exclude archived notices — valuable for interpreting results. It leaves out whether counts are exact or capped and how totals relate to the `top` truncation.

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?

First sentence states the operation and grouping options up front; the second supplies examples; the third/fourth qualify data coverage. No sentence is redundant and nothing important is buried.

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?

No output schema exists, and the description does explain that results are counts per group, which is the essential return shape. With 17 well-documented parameters and a required group_by, the definition covers what's needed to call it, though it could note whether a grand total is returned alongside groups.

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 coverage is 100% with per-parameter descriptions, so the baseline is 3. The description adds nothing beyond the schema about filter semantics — the group_by enum, date formats, and set-aside codes are all already documented in the parameter schemas.

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?

Opens with a specific verb and resource ('Count active SAM.gov notices grouped by agency…') and enumerates all ten grouping dimensions, so an agent immediately knows this aggregates rather than lists. That cleanly separates it from search_opportunities, which returns notice records.

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?

Explicitly states it accepts the same filters as search_opportunities and gives two concrete usage examples ('counts of open solicitations under one NAICS by set-aside', 'which agencies posted the most sources sought notices this quarter'). It never states an explicit when-not-to-use rule, but the sibling reference plus examples give a clear selection signal.

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.