Riveter MCP Server

Official

by riveterhq

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Run result

get_run_result

Read-onlyIdempotent

Fetch a Riveter run's result by ID, with optional long-polling up to 50 seconds to wait for completion and retrieve output once available.

Instructions

run result

The run plus output, null until the run finishes.

Pass ?wait=N (max 50) to long-poll: the request holds until the run finishes or the budget elapses, whichever comes first.

Output shape by run type

enrichment — an object mapping column headers to arrays of cell objects: { "Company": [{"value": "Apple"}], "CEO": [{"value": "Tim Cook"}] }
dataset_build — the same columnar shape as enrichment
extraction — the extracted records as an array of JSON objects (matching your output_record_json_schema)
quick_search — the search result object { "results": [{ "title", "link", "snippet" }, ...], "knowledge_graph"? }, the same data the synchronous POST /quick_search response already carried. (Runs started on the legacy async /web_search endpoint share this run type but return the columnar enrichment shape with a search_results column.)
search_agent — the answer object { "result": <string or object> }; result matches the request's output_schema when one was given, otherwise it's free text.
enrichment on a dataset (POST /enrich with dataset_id) — { "rows": [...] }: only the rows the fill ran, in position order, each in the /datasets/{id}/rows shape (id, position, input, cells limited to the columns the fill covered, credits). GET /datasets/{id}/rows is the live view. Above 5,000 rows, or after the rows expire (30 days), output is null and output_files (signed CSV and JSONL links to the whole grid; pending until the export lands, valid one hour, see expires_at) are the output.
enrichment started on POST /enrich_rows, or on POST /enrich with input — the columnar shape while rows are ≤ 5,000, plus the same output_files. Above 5,000 rows, or after the rows expire (30 days), output is null and the files are the output.

Workflow: output is null until the run finishes. Pass wait (seconds, max 50) to long-poll instead of sleeping between calls.

Input Schema

Name	Required	Description	Default
`id`	Yes	The run id (run_...)
`wait`	No	Long-poll budget in seconds (0–50, default 0)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.5Oct 29, 2026

TDQS

A4/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description adds value on top: the null-until-finished contract, the long-poll hold semantics, the 5,000-row threshold where `output` flips to `null`, 30-day row expiry, and `output_files` being signed links valid one hour with a `pending` state. These are exactly the non-obvious behaviors an agent needs and none of them are in the annotations.

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?

The header structure (Output shape by run type, Workflow) makes a long description scannable, and the length is justified by the absence of an output schema. It loses a point for the wasted 'run result' opener and for repeating the '>5,000 rows or 30-day expiry → `output` is null' rule three times in near-identical wording.

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?

With no output schema, the description carries the full return-shape burden and does so per run type, including the legacy `/web_search` caveat and the dataset-enrichment row shape. The remaining gap is that the run object's own fields (status, error) are never described, so an agent must discover elsewhere how to tell a finished run from a failed one.

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

Parameters4/5

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 beyond the schema by explaining what `wait` actually does — the request holds until the run finishes or the budget elapses, whichever comes first — rather than just stating a 0–50 range. `id` gets no added meaning beyond the schema's 'run_...' hint.

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

Purpose4/5

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

The body states concretely what is returned: the run object plus `output`, which is `null` until the run finishes, and it enumerates the payload shape per run type. That is far more specific than the tautological opening line 'run result', which merely restates the title. It never distinguishes itself from the sibling `get_run`, leaving the agent to infer the split.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

There is real usage guidance for polling: 'Pass `wait` (seconds, max 50) to long-poll instead of sleeping between calls' and a Workflow note repeating that `output` is null until the run finishes. However, no alternative is named — the sibling `get_run` exists and the description never says when to call that instead, nor what to do on expiry or error.

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