Search U.S. federal contract opportunities (RFPs, bids, awards) from SAM.gov official data.
Scored across 5 tools
The generic run/dataset/key-value tools are mostly distinct, and the SAM.gov Actor tool is clearly the domain search entry point. Some overlap exists between calling the Actor and then inspecting its run/results, but the descriptions provide enough guidance to choose correctly.
Four tools follow a readable kebab-case verb-object pattern, but the domain tool is named after the Actor package with a double hyphen and no verb, breaking the convention. The set is still understandable but not consistently patterned.
Five tools is a reasonable size and avoids bloat. However, only one tool is SAM.gov-specific, with the rest being generic Actor infrastructure, making the surface feel slightly thin for the stated domain.
The server can run a SAM.gov Actor search and retrieve dataset/key-value outputs, but there are no dedicated monitoring, notice-detail, or structured filter tools beyond the single Actor call. Core retrieval is covered, but domain lifecycle coverage is limited.
Abort an Actor run that is currently starting or running. For runs with status SUCCEEDED, FAILED, ABORTING, ABORTED, or TIMED-OUT, this call has no effect. The results will include the updated run details after the abort request.
USAGE:
Use when you need to stop a run that is taking too long or misconfigured.
USAGE EXAMPLES:
user_input: Abort run y2h7sK3Wc
user_input: Gracefully abort run y2h7sK3Wc
| Name | Required | Description | Default |
|---|---|---|---|
| runId | Yes | The ID of the Actor run to abort. | |
| gracefully | No | If true, the Actor run will abort gracefully with a 30-second timeout. |
| Name | Required | Description |
|---|---|---|
| tip | No | Advisory guidance RAG Web Browser wrote to its key-value store under the reserved "TIP" key |
| runId | Yes | Actor run ID |
| stats | No | Run statistics |
| status | Yes | Run status: READY | RUNNING | TIMING-OUT | TIMED-OUT | ABORTING | ABORTED | SUCCEEDED | FAILED |
| actorId | Yes | Stable Apify Actor ID from the run record |
| summary | Yes | Past-tense summary of the run state |
| exitCode | No | Actor process exit code; populated for terminal states (especially FAILED) |
| nextStep | Yes | One primary follow-up action with identifiers interpolated |
| storages | Yes | Dataset and key-value store metadata, keyed by alias. "default" is always the primary entry. |
| actorName | No | "username/actor-name" |
| startedAt | No | ISO timestamp when the run started |
| finishedAt | No | ISO timestamp when the run finished (terminal states only) |
| statusMessage | No | Pass-through from Apify run.statusMessage |
| apifyConsoleUrl | No | Personalized Apify Console link to the run; present only for Console sessions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the no-effect-on-terminal-states rule, which is exactly what makes the idempotent hint meaningful, plus the fact that updated run details come back. It omits auth/permission requirements and any rate-limit behavior.
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?
Front-loaded with the core action and the state constraint, and every prose sentence earns its place. The 'USAGE EXAMPLES' block of raw user_input lines is mostly decorative and pads the definition slightly.
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?
With an output schema present, return values need not be spelled out, and the description still notes that updated run details are returned. For a two-parameter mutation with full annotation coverage, only auth requirements are unaddressed, which is a minor gap.
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 both parameters and the 30-second graceful-abort timeout are already documented in the schema. The description only gestures at 'gracefully' via an example, adding no syntax or semantic meaning 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?
Specific verb (Abort) plus resource (Actor run) and a state qualifier ('currently starting or running'), which immediately distinguishes it from siblings like call-actor and get-actor-run. 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?
Explicit when-to-use ('stop a run that is taking too long or misconfigured') and an explicit no-op condition (terminal statuses such as SUCCEEDED, FAILED, ABORTED, TIMED-OUT). It does not name an alternative tool or describe prerequisites, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific Actor run.
Returns run result: status, storages (datasets/keyValueStores alias map), stats, summary, nextStep.
summary describes the past (e.g. "SUCCEEDED in 22s. 47 items; 3 fields available.").
nextStep prescribes one primary follow-up action with identifiers interpolated (e.g. "Use get-dataset-items with datasetId=...").
waitSecs (0–45, default 30) waits up to that many seconds for terminal status before returning.
USAGE:
Use to check the status of a run started by any Actor-running tool.
Pass waitSecs > 0 to block until terminal (or until the cap elapses).
USAGE EXAMPLES:
user_input: Show details of run y2h7sK3Wc
user_input: Wait for run y2h7sK3Wc to finish
| Name | Required | Description | Default |
|---|---|---|---|
| runId | Yes | The ID of the Actor run. | |
| waitSecs | No | Maximum seconds to wait for the run to reach a terminal state (SUCCEEDED, FAILED, ABORTED, TIMED-OUT). 0 returns immediately with the current status. Cap: 45. Default: 30. |
| Name | Required | Description |
|---|---|---|
| tip | No | Advisory guidance RAG Web Browser wrote to its key-value store under the reserved "TIP" key |
| runId | Yes | Actor run ID |
| stats | No | Run statistics |
| status | Yes | Run status: READY | RUNNING | TIMING-OUT | TIMED-OUT | ABORTING | ABORTED | SUCCEEDED | FAILED |
| actorId | Yes | Stable Apify Actor ID from the run record |
| summary | Yes | Past-tense summary of the run state |
| exitCode | No | Actor process exit code; populated for terminal states (especially FAILED) |
| nextStep | Yes | One primary follow-up action with identifiers interpolated |
| storages | Yes | Dataset and key-value store metadata, keyed by alias. "default" is always the primary entry. |
| actorName | No | "username/actor-name" |
| startedAt | No | ISO timestamp when the run started |
| finishedAt | No | ISO timestamp when the run finished (terminal states only) |
| statusMessage | No | Pass-through from Apify run.statusMessage |
| apifyConsoleUrl | No | Personalized Apify Console link to the run; present only for Console sessions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, but the description adds real behavioral context beyond them: the summary vs. nextStep semantics, and that waitSecs blocks for up to 45s (default 30) before returning the current state. This is substantive added value, though it doesn't cover error/failure modes.
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?
Front-loaded with the core purpose, then segmented into Returns/USAGE/EXAMPLES blocks. Every line carries information, though the two usage examples are somewhat redundant with the USAGE prose, adding minor length.
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?
With an output schema present and 100% parameter coverage, the description need only orient the agent, which it does fully: purpose, when to use, wait semantics, and concrete invocation examples. Nothing needed to call it correctly is missing.
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 baseline is 3, but the description goes further by framing waitSecs as a blocking/wait mechanism with its cap and default, and by describing what runId's run produces. Slight above-baseline value over the schema text.
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 ('Get detailed information about a specific Actor run') and enumerates the returned result fields (status, storages, stats, summary, nextStep). It does not explicitly distinguish itself from siblings like call-actor or abort-actor-run, so it falls just short of the 5 benchmark.
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 USAGE block names the condition ('check the status of a run started by any Actor-running tool') and explains when to pass waitSecs > 0 to block until terminal. It gives clear context but stops short of explicit exclusions or naming the sibling to use for other run operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get items (rows) from a dataset — the output/results produced by an Actor run. Returns the rows themselves, not dataset metadata, counts, or a schema. When the user provides a datasetId and asks to retrieve results, output, data, or rows, call this tool directly. Default limit is 20. Use clean=true to skip empty items and hidden fields.
USAGE:
Use when you need to read data from a dataset (all items or only selected fields).
USAGE EXAMPLES:
user_input: Retrieve results from dataset abc123
user_input: Get only metadata.url and title from dataset username~my-dataset
| Name | Required | Description | Default |
|---|---|---|---|
| desc | No | If true, results are returned in reverse order (newest to oldest). | |
| omit | No | Comma-separated list of fields to exclude from results. | |
| clean | No | If true, returns only non-empty items and skips hidden fields (starting with #). Shortcut for skipHidden=true and skipEmpty=true. | |
| limit | No | Maximum number of items to return. Default is 20. | |
| fields | No | Comma-separated list of fields to include in results. Fields in output are sorted as specified. Use dot notation for nested objects (e.g. "metadata.url"); the server auto-flattens parent prefixes. | |
| offset | No | Number of items to skip at the start. Default is 0. | |
| flatten | No | Comma-separated list of fields to flatten (e.g. flatten="metadata" turns {"metadata":{"url":"x"}} into {"metadata.url":"x"}). Normally derived automatically from dot-notation in `fields`; specify only as a diagnostic override. | |
| datasetId | Yes | Dataset ID or username~dataset-name. |
| Name | Required | Description |
|---|---|---|
| items | Yes | Dataset items |
| limit | Yes | Limit used for pagination |
| offset | Yes | Offset used for pagination |
| summary | Yes | Summary of the result |
| nextStep | Yes | One follow-up action with tool name |
| datasetId | Yes | Dataset ID |
| itemCount | Yes | Number of items returned |
| totalItemCount | Yes | Total items in dataset |
| apifyConsoleUrl | No | Personalized Apify Console link to the dataset; present only for Console sessions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already declaring readOnlyHint=true and idempotentHint=true, the description adds valuable behavioral context: returns rows themselves, default limit of 20, and clean=true behavior. It also clarifies the nature of the return value beyond the schema.
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?
Well-structured with clear USAGE and USAGE EXAMPLES sections. Some redundancy ('Get items (rows)...' and 'Returns the rows themselves...') but overall efficient and front-loaded with purpose.
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 tool has 8 parameters, an output schema, and rich annotations, the description adequately covers key behaviors, usage triggers, and examples. It doesn't explain every parameter but relies on the schema for that, which is appropriate.
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 baseline is 3. The description adds extra meaning by explaining default limit (20) and the clean=true shortcut, which supplements the schema. It also provides examples for fields usage, though most parameter semantics are in the 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?
Description clearly states the tool gets items (rows) from a dataset and explicitly distinguishes it from metadata, counts, or schema. It names the exact resource (dataset items) and the action (get), and provides direct trigger phrases for when to use it.
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?
Provides explicit use cases ('when the user provides a datasetId and asks to retrieve results...'), and clarifies what it is not for (metadata, counts, schema). However, it does not name alternative tools explicitly, only implies them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the value stored under a specific key in a key-value store — a single record, not a listing of all keys. Requires the exact key name. The response preserves the original Content-Encoding; most clients handle decompression automatically.
USAGE:
Use when you need to retrieve a specific record (JSON, text, or binary) from a store.
USAGE EXAMPLES:
user_input: Get record INPUT from store abc123
user_input: Get record data.json from store username~my-store
| Name | Required | Description | Default |
|---|---|---|---|
| recordKey | Yes | Key of the record to retrieve. | |
| keyValueStoreId | Yes | Key-value store ID or username~store-name. |
| Name | Required | Description |
|---|---|---|
| key | Yes | Record key |
| value | Yes | The stored value (JSON, text, or binary) |
| summary | Yes | Summary of the result |
| contentType | No | MIME type of the stored value |
| keyValueStoreId | Yes | Key-value store ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior. The description adds genuine context beyond that: the exact key name is required, and the response preserves the original Content-Encoding with most clients decompressing automatically. That encoding note is real operational value an agent would otherwise not know.
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?
Front-loaded with the core action and scope, then a short behavioral note, then usage. The USAGE line slightly overlaps the first sentence, but the examples earn their space by showing realistic inputs. No 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?
With an output schema present there is no need to describe return values, and the annotations carry the safety profile. For a two-parameter read tool, the description supplies everything else an agent needs: exactness of the key, allowed value types, and the encoding caveat.
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 the baseline is 3. The description still adds a semantic constraint the schema omits — that the key must be an exact match — and the examples show the 'username~my-store' form of the store ID, gently reinforcing the ID format.
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 (get) + resource (value under a key in a key-value store) with an explicit scope boundary: 'a single record, not a listing of all keys.' None of the sibling tools overlap with this resource, and the anti-scope clause removes any ambiguity about whether it enumerates keys.
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 USAGE line gives a clear triggering condition — retrieving a specific record (JSON, text, or binary) — and two concrete examples anchor it. It lacks explicit when-not-to-use guidance or named alternatives, but no similar sibling exists to route against.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
This tool calls the Actor "plainfold/sam-gov-contract-opportunities" and retrieves its output results. Actor description: Search U.S. federal contract opportunities from SAM.gov's official daily data extract: RFPs, solicitations, sources sought and award notices. Filter by keyword, NAICS, PSC, set-aside, agency, state and deadline, or monitor for new notices. No API key. $0.002/result + $0.002/run.
| Name | Required | Description | Default |
|---|---|---|---|
| sortBy | No | Result order. "relevance" (default): best keyword matches first (keyword in title > NAICS/PSC description > summary), ties broken newest first; with no keywords this is the same as newest first. "postedDateDesc": newest first. "deadlineAsc": soonest response deadline first (notices without a deadline last). Default: "relevance". Example values: "relevance" | relevance |
| agencies | No | Case-insensitive text matched anywhere in the department, sub-tier or office name, e.g. ["VETERANS AFFAIRS"], ["NAVFAC"], ["GENERAL SERVICES ADMINISTRATION"], ["ARMY"]. Default: [] (all agencies). | |
| keywords | No | Words or phrases to search for, e.g. ["cybersecurity", "zero trust"] or ["office furniture"]. Case-insensitive whole-word match, so "AI" won't match "maintain". By default keywords are matched in the title, the official NAICS and PSC code descriptions, and the notice summary (description with boilerplate FAR/DFARS clause text removed), so a parts notice that only cites a cybersecurity clause is not returned. Each result gets relevanceScore, matchedIn and matchedKeywords. [Description truncated] Example values: ["software"] | |
| pscCodes | No | Product Service Codes (PSC), full or prefix, e.g. ["D3"] for IT services, ["Z2"] for building repair, ["R4"] for professional support. A notice matches if its PSC starts with any entry. Default: [] (all PSCs). | |
| searchIn | No | Where keywords are matched. "titleAndDescription" (recommended): title, official NAICS/PSC code descriptions, and the first ~2,000 characters of the description after removing boilerplate FAR/DFARS clauses and standard compliance text. "title": title only (fewest, most precise results). "fullText": also searches the complete raw description including clause text (broadest; expect unrelated notices that only cite a clause). Default: "titleAndDescription". Example values: "titleAndDescription" | titleAndDescription |
| waitSecs | No | Max seconds (0–45, default 30) to cap the wait for the Actor run to reach terminal state. For long-running Actors the response returns at the cap with the current run status; follow `nextStep` to poll via get-actor-run. Set to 0 to fire-and-forget. | |
| setAsides | No | Only return notices with one of these set-aside codes, e.g. ["SBA"] for total small business, ["8A"], ["HZC"] for HUBZone, ["SDVOSBC"] for service-disabled veteran-owned, ["WOSB"]. Use ["NONE"] for full and open competition. Default: [] (any set-aside). | |
| maxResults | No | Maximum number of results to return; each result costs $0.002, so 100 results is about $0.20. 0 means no limit (a full export is about 50,000 unique opportunities). Default: 500. Example values: 100 | |
| naicsCodes | No | NAICS industry codes, full or prefix, e.g. ["541512"] or ["5415"] (prefix "5415" matches 541511, 541512, 541519 and so on). A notice matches if its NAICS code starts with any entry. Default: [] (all industries). | |
| monitorName | No | Name of the monitoring memory used when onlyNewSinceLastRun is true, e.g. "va-cyber-daily". Use a different name for each saved search. Default: "default". Example values: "default" | default |
| noticeTypes | No | Only return these notice types, e.g. ["Solicitation", "Combined Synopsis/Solicitation"] for biddable opportunities, ["Sources Sought", "Presolicitation"] for early pipeline, or ["Award Notice"] to see who won what. Default: [] (all types). | |
| postedAfter | No | Only notices posted on or after this date, format YYYY-MM-DD, e.g. "2026-10-01". Default: no date limit. | |
| keywordMatch | No | "any" returns notices containing at least one keyword; "all" returns only notices containing every keyword. Default: "any". Example values: "any" | any |
| minAwardAmount | No | For award notices: only awards of at least this many U.S. dollars, e.g. 1000000 for $1M+. 0 means no limit. Notices without an award amount are excluded when this is set. Default: 0. | |
| excludeKeywords | No | Skip notices that mention any of these words or phrases (matched in the same places as keywords, per searchIn), e.g. ["construction", "janitorial"]. Default: []. | |
| includeContacts | No | Add the government point(s) of contact listed on each notice (name, work email, work phone). Default: false. | |
| postedWithinDays | No | Only notices posted or updated in the last N days, e.g. 7 for the past week or 1 for a daily check. 0 means no limit. Default: 0. Example values: 7 | |
| latestVersionOnly | No | SAM.gov lists every amendment as a separate notice (about 40% of raw rows are older versions). If true, you get one result per opportunity (the latest version) with a versionCount, and filters apply to that version. If false, every version is its own row. Default: true. Example values: true | |
| deadlineWithinDays | No | Only notices whose response deadline falls within the next N days, e.g. 14. 0 means no limit. Default: 0. | |
| includeDescription | No | Include the notice description as plain text in each result. Set false for smaller, cheaper-to-process output. Default: true. Example values: true | |
| onlyNewSinceLastRun | No | Monitoring mode for scheduled runs: return only notices this monitor (see monitorName) hasn't delivered before, so you pay only for new results. The first run returns everything that matches. Default: false. | |
| descriptionMaxLength | No | Trim each description to this many characters, e.g. 500 for short summaries. 0 means the full text (SAM.gov caps it at about 32,000). Default: 2000. Example values: 2000 | |
| onlyOpenForResponses | No | If true, only notices whose response deadline is still in the future (biddable now). Notices without a deadline, including most award notices, are excluded. Default: false. | |
| includeUpdatedNotices | No | In monitoring mode, also return notices that were amended or re-posted since this monitor last delivered them (marked changeType = "updated"). Default: true. Example values: true | |
| placeOfPerformanceStates | No | Two-letter U.S. state codes for the place of performance, e.g. ["TX", "VA"]. Many notices don't list a place of performance, and those are excluded when this filter is used. Default: [] (no state filter). |
| Name | Required | Description |
|---|---|---|
| tip | No | Advisory guidance RAG Web Browser wrote to its key-value store under the reserved "TIP" key |
| runId | Yes | Actor run ID |
| stats | No | Run statistics |
| status | Yes | Run status: READY | RUNNING | TIMING-OUT | TIMED-OUT | ABORTING | ABORTED | SUCCEEDED | FAILED |
| actorId | Yes | Stable Apify Actor ID from the run record |
| summary | Yes | Past-tense summary of the run state |
| exitCode | No | Actor process exit code; populated for terminal states (especially FAILED) |
| nextStep | Yes | One primary follow-up action with identifiers interpolated |
| storages | Yes | Dataset and key-value store metadata, keyed by alias. "default" is always the primary entry. |
| actorName | No | "username/actor-name" |
| startedAt | No | ISO timestamp when the run started |
| finishedAt | No | ISO timestamp when the run finished (terminal states only) |
| statusMessage | No | Pass-through from Apify run.statusMessage |
| apifyConsoleUrl | No | Personalized Apify Console link to the run; present only for Console sessions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=true, and the description adds real context: cost per result and per run ($0.002 + $0.002), that no API key is needed, and that monitoring persists state across runs. It does not contradict the write/destructive hint — monitoring mode does write state — but it also doesn't explain the run lifecycle or what happens on timeout.
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, with the substantive actor description up front and no filler afterwards. The opening wrapper sentence ("This tool calls the Actor ... and retrieves its output results") is low-value boilerplate that slightly dilutes the front-loading.
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?
With 25 optional parameters, full schema coverage, an output schema, and annotations present, the description covers everything an agent needs at the call site: what data source, what can be filtered, that monitoring mode exists, and what it costs. Run polling details are documented in the waitSecs schema rather than needing duplication here.
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% across all 25 parameters, so the schema already carries the semantics and baseline is 3. The description only recaps filter categories (keyword, NAICS, PSC, set-aside, agency, state, deadline) without adding syntax, semantics or precedence rules beyond what the schema states.
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 names a specific verb and resource: searching U.S. federal contract opportunities from SAM.gov's official daily extract, covering RFPs, solicitations, sources sought and award notices. It enumerates the filterable dimensions and mentions the monitoring mode, which makes it unmistakable against generic Apify siblings like get-dataset-items or get-actor-run.
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?
It hints at two usage modes ("Filter by ... or monitor for new notices") but never states when to prefer this tool, when to fall back to a sibling, or what prerequisites exist. Guidance is implied by the filter list rather than explicit conditions, so it lands at minimum viable.
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.
plainfold--sam-gov-contract-opportunities2 fields changedOutput schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / solicitationNumber / typePrevious value: -[
- "null",
- "string"
-]New value: +[
+ "string",
+ "null"
+]Output schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / subTier / typePrevious value: -[
- "string",
- "null"
-]New value: +"string"plainfold--sam-gov-contract-opportunities2 fields changedOutput schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / solicitationNumber / typePrevious value: -[
- "string",
- "null"
-]New value: +[
+ "null",
+ "string"
+]Output schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / subTier / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]plainfold--sam-gov-contract-opportunities2 fields changedOutput schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / solicitationNumber / typePrevious value: -[
- "null",
- "string"
-]New value: +[
+ "string",
+ "null"
+]Output schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / subTier / typePrevious value: -[
- "string",
- "null"
-]New value: +"string"plainfold--sam-gov-contract-opportunities2 fields changedOutput schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / solicitationNumber / typePrevious value: -[
- "string",
- "null"
-]New value: +[
+ "null",
+ "string"
+]Output schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / subTier / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]plainfold--sam-gov-contract-opportunities2 fields changedOutput schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / solicitationNumber / typePrevious value: -[
- "null",
- "string"
-]New value: +[
+ "string",
+ "null"
+]Output schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / subTier / typePrevious value: -[
- "string",
- "null"
-]New value: +"string"plainfold--sam-gov-contract-opportunities2 fields changedOutput schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / solicitationNumber / typePrevious value: -[
- "string",
- "null"
-]New value: +[
+ "null",
+ "string"
+]Output schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / subTier / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]plainfold--sam-gov-contract-opportunities2 fields changedOutput schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / solicitationNumber / typePrevious value: -[
- "null",
- "string"
-]New value: +[
+ "string",
+ "null"
+]Output schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / subTier / typePrevious value: -[
- "string",
- "null"
-]New value: +"string"plainfold--sam-gov-contract-opportunities2 fields changedOutput schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / solicitationNumber / typePrevious value: -[
- "string",
- "null"
-]New value: +[
+ "null",
+ "string"
+]Output schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / subTier / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Government contract search and federal procurement data: SAM.gov opportunities + USASpending awards.
US federal contracting data: open solicitations, buying agencies, contractors, price history.
SAM.gov federal contracts: search, details, AI bid analysis. 33k+ live opportunities.
SAM.gov contract opportunities and entity lookup (BYOK) plus USASpending federal award data.
Add one secure layer between your agents and this server.
