Clean annual and quarterly company financials from official SEC EDGAR XBRL data.
Score is being calculated.
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 and readOnlyHint=false, so the safety profile is covered. The description adds genuinely new behavior beyond the annotations: the call is a no-op for SUCCEEDED/FAILED/ABORTING/ABORTED/TIMED-OUT runs, and the response returns the updated run details. It does not mention permission requirements or 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 action and its status preconditions before the USAGE block, and no sentence is wasted. The USAGE EXAMPLES lines are thin (one is a bare restatement of the required runId) but the graceful variant does demonstrate a real parameter usage.
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 detailed, and the description correctly just notes that updated run details come back. Purpose, preconditions, and usage are all covered; only permission/auth context is missing for a destructive, openWorld=false operation.
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 both parameters (runId, gracefully with its 30-second timeout) are fully documented in the schema, so the baseline is 3. The description adds little parameter meaning beyond the example 'Gracefully abort run y2h7sK3Wc', which only loosely illustrates the gracefully flag.
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 ('Abort an Actor run') and narrows scope with the precondition 'currently starting or running', which makes the operation unambiguous. It never names a sibling such as get-actor-run to contrast against, but the destructive abort semantics are self-evidently distinct from the read-only tools in the sibling list.
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?
'Use when you need to stop a run that is taking too long or misconfigured' gives a clear triggering condition, and the status no-op list functions as an implicit when-not-to-use rule for terminal runs. No alternative tools or host-level prerequisites (auth, workspace scoping) are offered, so it stops short of a full routing guide.
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 readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: the blocking semantics and 45s cap of waitSecs, the meaning of summary (describes the past) and nextStep (prescribes one interpolated follow-up), which an agent needs to interpret the response.
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 purpose, then USAGE, then examples, with every line carrying information: field list, summary/nextStep semantics, and the waitSecs contract. No filler sentences, and the examples are short and directly actionable.
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 explained, yet the description usefully characterizes summary and nextStep so the agent can act on them. Purpose, parameters, blocking behavior and examples are all covered; only auth/permission prerequisites for reading another Actor's run are unstated, 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 coverage is 100%, so both parameters are already documented in the schema with min/max/default and terminal-state enumeration. The description's waitSecs line ('0-45, default 30, waits up to that many seconds for terminal status') largely restates the schema, adding no syntax or format beyond it, 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 gives a precise verb+resource ('Get detailed information about a specific Actor run') and enumerates the returned fields (status, storages, stats, summary, nextStep). It does not explicitly contrast itself with the sibling abort-actor-run, but the phrasing 'a run started by any Actor-running tool' makes its read-only inspection role clear.
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 section states when to reach for it ('check the status of a run started by any Actor-running tool') and how to make it block via waitSecs > 0, reinforced by two concrete user_input examples. It stops short of stating when NOT to use it (e.g. versus abort-actor-run or a listing tool), so it is clear context without exclusions.
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 establish readOnlyHint, idempotentHint, and destructiveHint as false. The description adds valuable behavioral context beyond this: the exact key name requirement and the preservation of Content-Encoding with automatic client decompression. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a concise opening definition, a short behavioral note, and clear usage examples. Every section earns its place without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read-only tool with full schema coverage, an output schema, and strong annotations, the description covers the essential context: how to target a record, what to expect (Content-Encoding), and when it applies. The sibling context also helps differentiate it from listing operations.
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?
Input schema coverage is 100%, so the schema already documents both parameters. The description adds usage examples and the 'exact key name' requirement, but these are minimally additive beyond the schema's own property descriptions.
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 uses a specific verb and resource: 'Get the value stored under a specific key in a key-value store.' It also distinguishes itself by explicitly stating this is 'a single record, not a listing of all keys,' which separates it from sibling tools like 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?
The description provides a clear usage context: 'Use when you need to retrieve a specific record (JSON, text, or binary) from a store.' It does not name alternative tools explicitly, but the 'not a listing of all keys' phrase gives implicit exclusion guidance for listing-style operations.
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 |
Search SEC EDGAR filings, financial statements, and company data.
SEC Financial Statement & Notes data sets — dimensional facts + note text.
SEC filings, financial statements, metrics, insider and institutional holdings as structured data
Verified SEC filing data for US equities: fundamentals, point-in-time values, 13F holders, insiders
Add one secure layer between your agents and this server.
