SEC Company Financials

Get dataset items

get-dataset-items

Read-onlyIdempotent

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

Input Schema

Name	Required	Description
`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, name (resolved against your own datasets), or full name as username~name.

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 29, 2026

changedInput schema / properties / datasetId / description

Previous value: -"Dataset ID or username~dataset-name."New value: +"Dataset ID, name (resolved against your own datasets), or full name as username~name."

First observedOct 9, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), so the description adds value by disclosing the default limit of 20, what clean=true does, and that results are the raw rows. Return-shape details are largely deferred to the existing output schema, which is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose and the anti-scope sentence, followed by short usage notes and examples. Slightly redundant in repeating the limit default and the clean flag across sections, but nothing wasteful enough to hurt.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read tool with full schema coverage and an output schema, the description supplies the purpose, trigger, and key defaults an agent needs. Pagination interaction (offset/limit) and flatten behavior are left to the schema, which is reasonable given the output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all eight parameters in depth. The description only restates the default limit and clean=true semantics, adding little beyond the structured fields; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get items (rows) from a dataset') and immediately delimits scope by saying it returns rows themselves, not metadata, counts, or schema. An agent can distinguish the intent 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.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear trigger ('When the user provides a datasetId and asks to retrieve results, output, data, or rows, call this tool directly') plus a usage section and two concrete examples. It lacks explicit when-not guidance relative to any alternative, but the sibling list contains no competing dataset-read tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All SEC Company Financials tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.