US federal contract opportunities from SAM.gov: NAICS-filtered solicitations, set-aside alerts, near-expiry deadlines, updated daily.
Scored across 3 tools
Each tool targets a clearly distinct use case: gov.digest is a NAICS-only routine feed, gov.near_expiry is a pure deadline-window urgency scan, and gov.search is a full multi-filter research query. The descriptions explicitly contrast each against the others, eliminating selection ambiguity.
All three tools share a consistent gov. namespace with snake_case suffixes, which is predictable. Minor deviation: digest and search read as actions while near_expiry is a descriptive modifier rather than a parallel verb form.
Three tools is on the lean side but defensible for a focused read-only monitoring 'radar' — digest, urgency triage, and search each earn their place without overlap. It is slightly under-scoped rather than excessive.
The discovery/monitoring domain is well covered across routine, urgency, and filtered-research paths. The main gap is no dedicated way to retrieve full opportunity descriptions or attachments for a single notice, though search results partially compensate.
Daily briefing for one NAICS code: a compact, chronological list of the most recently posted opportunities (title, agency, type, deadline, posting time) for routine monitoring of your market. Unlike gov.search, it takes only a NAICS code and returns a short digest - no keyword/type filters, no full descriptions. Use this as the routine morning check on what is new for your industry.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max digest items (default 5). | |
| naics | Yes | NAICS code, e.g. '541511'. Required. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds that the output is a short chronological digest limited by default, but does not explain ordering guarantees, pagination, or what 'most recently posted' means precisely (post time vs. deadline). Adequate but not rich.
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, front-loaded with the core purpose, then fields, then differentiation. Slightly dense with parenthetical field list, but no wasted sentences.
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 two-parameter read tool with no output schema, the description covers purpose, scope, and differentiation from the named sibling. It could note ordering/tie-breaking or pagination beyond the default limit, but the essentials are present.
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 both parameters documented (naics required, limit default 5). The description only echoes that it takes a NAICS code and returns a short digest; it adds no syntax, format, or edge-case detail beyond the schema. Baseline 3 is correct when the schema does the heavy lifting.
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?
Specific verb+resource (daily briefing/digest for one NAICS code) with explicit scope and listed fields. It distinguishes itself from the named sibling gov.search by noting no keyword/type filters and no full descriptions.
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 frames the tool as the routine morning monitoring check and contrasts it against gov.search, which takes filters. The agent knows exactly when this tool is the right choice versus the sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deadline-driven urgency triage: opportunities that close within N days, sorted by urgency (closest deadline first), each with daysLeft until close. Unlike gov.search or gov.digest, this ignores keywords and freshness - it is purely a time-window scan for last-minute bidding, bid deadline reminders and pipeline management.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Closing within how many days (default 7). | |
| naics | No | Optional NAICS filter to narrow the window. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive), so the bar is lower. The description still adds real behavioral context: results are sorted closest-deadline-first and each item carries a daysLeft field. It stops short of stating limits/pagination or an empty-window behavior, so not a 5.
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, zero filler: the mechanism and sort order lead, the sibling differentiation follows. Every clause carries information an agent needs.
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 2-parameter, no-output-schema tool, the description supplies the return shape (urgency-sorted with daysLeft) and the temporal scoping. It is essentially complete, missing only edge-case behavior such as what an empty result or a very large N yields.
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 'days' and 'naics' are already documented with their defaults and optionality. The description reinforces the N-day window concept but adds no syntax, range, or interaction detail (e.g., how naics narrows the window) beyond the schema. 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?
States a specific verb+resource+mechanism: a deadline-window scan of opportunities closing within N days, sorted by urgency. It explicitly names gov.search and gov.digest and says what makes this one different (ignores keywords and freshness), so an agent can select it without opening the schema.
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?
Names the two sibling alternatives and the condition that rules them out ('this ignores keywords and freshness'), then lists concrete use cases (last-minute bidding, deadline reminders, pipeline management). When-to-use and when-not-to-use are both explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explore and answer questions about federal contract opportunities. Combine any filters - NAICS code, free-text keyword, set-aside type, posting window - and get full fields (title, agency, type, NAICS, set-aside, deadline, official posting date (postedDate) plus exact time (postedAt) where available, SAM.gov link). Use this when you need to research a specific market, match a capability, or compare opportunities. Data synced hourly via GovConAPI (latency ≤60 min); SAM fallback every 6h.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | How many days back to search (default 7). | |
| naics | No | NAICS code to filter by, e.g. '541511'. Optional - omit for all. | |
| keyword | No | Free-text keyword in the title, e.g. 'IT services'. Optional. | |
| setAside | No | Set-aside filter: 8(a), WOSB, HUBZone, SDVOSB, SBA, or empty for all. Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds meaningful operational context beyond annotations: data is synced hourly via GovConAPI with latency ≤60 min and a SAM fallback every 6h. It does not cover rate limits or pagination, but given the annotations, this is a solid addition.
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 purpose, then filters and return fields, then use cases, then data freshness. It is dense but every sentence contributes useful information. Slightly long, but no wasted or repetitive sentences.
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 covers purpose, available filters, return fields, use cases, and data freshness. Annotations cover the safety profile, and no output schema exists so return fields are described directly. Missing pagination or result-limit details, but otherwise complete for an agent to call 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 description coverage is 100%, so each parameter is already documented in the input schema. The description lists the filter categories and notes they can be combined, which adds slight semantic value, but it does not add format details or constraints beyond what the schema provides. Baseline 3 is appropriate when the schema carries the parameter burden.
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?
States a specific verb and resource: 'Explore and answer questions about federal contract opportunities.' It details the filters and return fields, making the tool's scope clear. However, it does not distinguish this tool from its siblings gov.digest and gov.near_expiry, which would require an agent to infer the difference from names alone.
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?
Gives clear when-to-use guidance: 'Use this when you need to research a specific market, match a capability, or compare opportunities.' It does not mention when not to use it or name alternative sibling tools, so the agent receives context but no explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
gov.digest1 field changedInput schema / properties / limit / descriptionPrevious value: -"Max results (default 5)."New value: +"Max digest items (default 5)."gov.near_expiry1 field changedInput schema / properties / naics / descriptionPrevious value: -"Optional NAICS filter."New value: +"Optional NAICS filter to narrow the window."gov.digestgov.near_expirygov.search
Add one secure layer between your agents and this server.