Plainfold data tools: SAM.gov contracts, business entity checks, hiring signals, SEC financials.
Scored across 8 tools
The four platform tools (abort-actor-run, get-actor-run, get-dataset-items, get-key-value-store-record) each target a clearly different resource and action, and the four plainfold-- Actor wrappers cover distinct data domains (registration, hiring, contracts, financials). The only residual overlap is that three of the Actor tools all answer 'tell me about this company', so an agent may need to weigh which actor to invoke for a broad company query.
Platform tools follow a consistent verb-noun kebab-case pattern (get-/abort- + resource), and the four Actor wrappers share a uniform 'plainfold--<actor-name>' namespace prefix. The two families use different conventions (verb-first vs. namespaced noun phrases), which is a readable and predictable split rather than a chaotic mix.
Eight tools is well within the healthy range, and every entry earns its place: four cover run/dataset/key-value lifecycle reads and control, four expose distinct paid data actors. Nothing looks redundant or padded.
Reads and control are covered (get run, abort run, read dataset items, read KV record), and the Actor wrappers implicitly start runs, but there is no explicit tool to start/execute an arbitrary Actor run, nor any listing tools for runs, datasets, or key-value stores. Agents cannot discover resource IDs or drive a generic actor workflow, only the four hardwired ones.
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/business-entity-check" and retrieves its output results. Actor description: Verify a US company is registered and active from official state registry open data (NY, CO, OR, CT, TX). Returns verdict, legal name, registry ID, status, entity type, formation date, address. Company records only, no API key. $0.004 per company found, $0.0005 per no-match.
| Name | Required | Description | Default |
|---|---|---|---|
| states | No | Which state registries to search. Default: all supported states ["NY", "CO", "OR", "CT", "TX"]. NY and OR publish active entities only; CO and CT include inactive entities with their status; TX reports the Comptroller's right-to-transact-business status. Example values: ["NY","CO","OR","CT","TX"] | |
| 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. | |
| companies | Yes | **REQUIRED** Legal or common names of the companies to verify, one per entry, e.g. ["Arrow Electronics, Inc.", "Kodak Alaris LLC"]. Matching ignores case, punctuation, a leading "The" and suffix spelling (Inc./Incorporated, LLC/L.L.C.). A name without a suffix ("Arrow Electronics") matches any entity type; a name with a suffix ("AT&T Corp") prefers that exact entity. To search one state only, append " | XX", e.g. "Dell Technologies Inc. | TX". One result (and one charge) per entry. [Description truncated] Example values: ["Arrow Electronics, Inc.","Kodak Alaris LLC"] | |
| includeSimilar | No | Add up to 5 similar registered names (e.g. subsidiaries such as "Arrow Electronics Funding Corporation") in similarNames. Similar names never count as a match. Default: true. Example values: true | |
| includeInactive | No | Also return dissolved, withdrawn, forfeited or revoked registrations (marked isActive: false). Set false to return only active or status-unknown registrations. Default: true. Example values: true | |
| maxMatchesPerCompany | No | Maximum matching registrations listed per company (across all states), best first. Default: 10. Example values: 10 |
| 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 readOnlyHint=false, openWorldHint=true and destructiveHint=true, so the safety profile is partly covered. The description adds genuinely useful context beyond that: per-company pricing ($0.004 found / $0.0005 no-match), 'no API key' requirement, and that mismatches/similar names never count as a match. It does not explain the destructive/side-effect nature implied by the annotations, but the cost model and matching semantics are real added value.
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 compact sentences with no wasted words; the generic 'calls the Actor and retrieves its output results' lead is boilerplate but brief, and the substantive Actor description follows immediately. Front-loading the actual capability would have been marginally better.
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?
An output schema exists, so return values need not be re-explained, yet the description still summarizes the key fields. It communicates pricing, state coverage, matching behavior and no-auth-required, which is sufficient for a 6-param, single-required-param verification tool. Only usage routing relative to siblings 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 description coverage is 100% and each of the 6 parameters (states, waitSecs, companies, includeSimilar, includeInactive, maxMatchesPerCompany) is documented in detail in the schema itself. The description adds little parameter-level meaning beyond the billing note ('one result, one charge per entry'), so the 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?
The Actor description states a specific verb, resource and scope: 'Verify a US company is registered and active from official state registry open data (NY, CO, OR, CT, TX)'. It also enumerates the result shape (verdict, legal name, registry ID, status, entity type, formation date, address), which distinguishes it at a glance from the generic Apify plumbing siblings (get-actor-run, get-dataset-items).
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?
Usage is only implied by the subject matter: it is the tool you use when you need to confirm a US company's registration. There is no explicit when-to-use/when-not statement and no routing to or away from any sibling (e.g. how it relates to get-dataset-items for fetching more results). The 'Company records only' line is a mild scope exclusion.
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/company-hiring-signals" and retrieves its output results. Actor description: Get any company's open jobs from its website: auto-detects Greenhouse, Lever, Ashby, Workable, SmartRecruiters, Recruitee & more. Normalized jobs plus a hiring summary: departments, locations, new roles, velocity. No API key. $0.003/company, $0.001/job, $0.0005/run.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| companies | Yes | **REQUIRED** Companies to check, one per entry. Best: the company website domain ("ramp.com"); the Actor reads its homepage and careers page to find the job board, then falls back to the board name on each supported ATS. Also accepted: a job-board URL ("https://jobs.lever.co/spotify", "https://job-boards.greenhouse.io/stripe"), "ats:slug" ("greenhouse:stripe", "ashby:ramp", "smartrecruiters:ServiceNow") or a plain company name ("Hugging Face"; least reliable). [Description truncated] Example values: ["ramp.com","https://jobs.lever.co/spotify","greenhouse:stripe"] | |
| remoteOnly | No | Return only jobs that can be done remotely (remote: true). Default: false. | |
| includeJobs | No | Return one dataset item per job (charged per job). Set false to get only the per-company hiring summaries (cheapest way to monitor many companies). Default: true. Example values: true | |
| postedSince | No | Optional: return only jobs first posted on or after this point, for monitoring new roles. Either a date ("2026-10-01") or a window back from now ("24 hours", "7 days", "2 weeks", "1 month"). Jobs without a posting date (BambooHR) are excluded when this is set. The company summary always describes all open roles and adds newSinceCount. Empty = all open jobs. | |
| titleKeywords | No | Optional: return only jobs whose title contains any of these words (case-insensitive), e.g. ["engineer", "sales"]. The summary still covers all roles. | |
| locationKeywords | No | Optional: return only jobs whose location or country contains any of these, e.g. ["New York", "Remote", "GB"]. | |
| maxJobsPerCompany | No | Maximum jobs returned per company after filters, newest first (each job is one charge). The summary always counts every open role. Default: 200. Example values: 200 | |
| includeDescription | No | Add a plain-text description (up to 4,000 characters, emails and phone numbers removed) to each job where the ATS feed provides one (not SmartRecruiters, Breezy or BambooHR). Makes output larger. Default: false. |
| 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 openWorldHint and destructiveHint, and the description adds genuinely useful context the annotations don't carry: explicit per-run pricing ($0.003/company, $0.001/job, $0.0005/run), no API key requirement, and which ATSs are auto-detected. It does not explain the run lifecycle or the waitSecs cap, but the schema covers that. No contradiction with the declared write/destructive profile, since this spawns paid Actor runs.
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 compact parts: the wrapper framing and the actor description, both front-loaded with the capability and pricing. Some marketing cadence ('& more', the price triplet) but every clause conveys selection-relevant information; nothing needs trimming urgently.
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, the description needn't explain return shapes, yet it still summarizes outputs (normalized jobs, departments, locations, velocity) and cost model. For a 9-parameter, outbound-scraping tool the only real gap is guidance on run duration/polling, which the schema's waitSecs text handles.
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% and each of the 9 parameters is thoroughly documented in the schema (accepted input formats, charge behavior, filtering side-effects). The description adds no parameter-level meaning beyond what the schema already states, so the 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?
The description combines a wrapper sentence ('calls the Actor ... and retrieves its output results') with a concrete actor summary: 'Get any company's open jobs from its website: auto-detects Greenhouse, Lever, Ashby...' plus normalized jobs and a hiring summary. That is a specific verb+resource an agent can match against siblings like sec-company-financials or sam-gov-contract-opportunities. The leading boilerplate about calling an Actor adds nothing but does not obscure the purpose.
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?
Usage context is implied (monitoring companies' open roles, finding new postings by department/location) and the schema's includeJobs note hints at the 'cheapest way to monitor many companies'. However, the description never states when to pick this over the sibling data actors, nor any exclusions or prerequisites beyond 'No API key'.
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.
This tool calls the Actor "plainfold/sec-company-financials" and retrieves its output results. Actor description: Clean annual and quarterly financials from official SEC EDGAR filings: revenue, net income, EPS, cash flow, assets, liabilities, cash, margins, YoY growth and TTM, plus company info and latest filings. Tickers, CIKs or names. No API key. $0.005/company, $0.0005/run.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| companies | Yes | **REQUIRED** Companies to look up, one per entry. Accepts a stock ticker ("AAPL", "BRK.B"), an SEC CIK ("320193" or "0000320193") or a company name ("Figma", "Ford Motor"). ALL-CAPS short entries are read as tickers first; write "name:Ford" or "ticker:FORD" to force one. Works for US companies and foreign companies that file with the SEC (20-F/40-F filers such as ASML or TSMC). One result (and one charge, only if financial data is returned) per entry. Up to 500 per run. Example values: ["AAPL","Figma","ASML"] | |
| maxFilings | No | Maximum number of filings listed per company, newest first. Default: 15. Example values: 15 | |
| filingForms | No | Optional: list only these form types in `filings`, e.g. ["10-K", "10-Q", "8-K"] or ["20-F", "6-K"]. Empty = all forms except insider/ownership forms and 424B2/424B3/424B7/FWP. | |
| annualPeriods | No | Number of most recent fiscal years to return in `annual` (from 10-K, 20-F or 40-F filings), newest first. 0 = none. Default: 5. Example values: 5 | |
| includeFilings | No | Add the company's latest SEC filings (form, filing date, period, description, 8-K item numbers, document and index links) in `filings`. Insider and ownership forms (3, 4, 5, 144, 13D/G, 13F) and high-volume offering paperwork (424B2, 424B3, 424B7, FWP) are left out unless you list them in `filingForms`. Default: true. Example values: true | |
| quarterlyPeriods | No | Number of most recent fiscal quarters to return in `quarterly`, newest first. Q4 and quarterly cash flow are derived from year-to-date figures when the filing doesn't state them (flagged in `derived`). Foreign 20-F/40-F filers usually have no quarterly XBRL data. 0 = none. Default: 8. Example values: 8 |
| 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 readOnlyHint=false, destructiveHint=true and openWorldHint=true, so the safety profile is largely covered structurally. The description adds genuine value with cost transparency ('$0.005/company, $0.0005/run'), but it does not disclose the run lifecycle (that it starts a billable Actor run and may return non-terminal results within waitSecs) and 'retrieves its output results' sits in mild tension with destructiveHint=true.
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: a short wrapper statement followed by a dense, information-rich actor summary. It is front-loaded and mostly free of filler, though the 'This tool calls the Actor ... and retrieves its output results' preamble is near-tautological and the 'Actor description:' label is boilerplate overhead.
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 no explanation, and annotations plus the 100%-covered schema carry safety and parameter detail. The description supplies data scope, input flexibility and pricing, making it broadly complete; the only real gap is operational context about the run/poll lifecycle in an agentic workflow.
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 all seven parameters (waitSecs, companies, maxFilings, filingForms, annualPeriods, includeFilings, quarterlyPeriods) are already fully documented in the schema. The description only echoes the accepted identifier types ('Tickers, CIKs or names'), matching the baseline 3 for a schema that 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?
The actor description names a specific verb+resource well beyond a tautology: it returns SEC EDGAR financials (revenue, net income, EPS, cash flow, margins, TTM) and accepts tickers, CIKs or names. However, the framing sentence ('calls the Actor ... and retrieves its output results') is generic wrapper boilerplate, and it never explicitly differentiates itself from the platform-level siblings (get-dataset-items, get-actor-run), so it lands at 4 rather than 5.
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?
Usage is implied by the subject matter (fetch SEC company financials when you need reported fundamentals), and it notes 'No API key' and per-company run pricing. But there is no explicit when-to-use vs when-not guidance, no mention of the siblings, and no note about the async/run-then-poll flow that would tell an agent when this is the right entry point versus get-actor-run or get-dataset-items.
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"
+]US government + SEC data as clean JSON: SAM.gov, USAspending, Grants.gov, Congress, SEC filings.
US public-records intelligence for AI agents — companies, SEC, courts, spending, licenses.
Federal contracts, FDA recalls, business registrations, Amazon products — B2B intel.
Funding rounds, exec moves, UCC liens and Form 5500 plans. 7 tools need no API key.
Add one secure layer between your agents and this server.