Skip to main content
Glama
riveterhq

Riveter MCP Server

Official
by riveterhq
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Enrich

enrich

Adds AI-researched columns to dataset rows or inline input, filling pending, stale, or failed cells with researched values.

Instructions

enrich

Add AI-researched columns to rows. Rows come from exactly one of dataset_id (ds_..., preferred) or input (inline, columnar: { "Header": ["row1", "row2"] }, all arrays equal length; a one-off, nothing kept).

Preferred: put the rows in a dataset first (build_dataset with rows + attributes or enrichment_id, free; it keeps the rows and filled cells), then enrich with its dataset_id: fills its cells with its enrichment; no column config needed. Default scope: every pending, stale, or failed cell; columns, rows, positions narrow it; force: true re-runs filled cells. prompt + attributes fills the named columns, adding the missing ones first; output is refused (update_dataset sets a column's prompt / schema / tool). help with datasets.

With input, column config is exactly one of, most consistent first:

  1. enrichment_id — a saved enrichment (enr_..., list_enrichments): fixed, tested config; up to 10,000 rows; input headers must match its input columns (get_enrichment).

  2. prompt + attributes — the task and up to 20 column names; no setup; up to 1,000 rows.

  3. output — per column prompt, optional output_schema, optional pinned tool; up to 1,000 rows. help with column_config or examples first.

Returns a run. Poll get_run_result with wait: 50 (or pass webhook_url); a dataset fill's result is { "rows": [...] }, only the rows it ran. estimate_cost: true prices it without running. A legacy key in the response means the call took a legacy mode (a legacy enrichment's id, legacy-pipeline column fields); follow legacy.successor.

Example — Run a saved enrichment: { "enrichment_id": "enr_018f5b60-1234-7abc-89ab-0123456789ab", "input": { "Company Name": [ "Acme Corp", "Tech Solutions Inc" ] } }

Example — Prompt + attributes (a task and column names): { "prompt": "Research each company", "attributes": [ "CEO", "Employee Count", "Industry" ], "input": { "Company": [ "Apple", "Google" ] }, "webhook_url": "https://your-server.com/webhook" }

Example — A spec per output column: { "output": { "Employee Count": { "prompt": "Find the number of employees at this company", "output_schema": { "type": "integer" } } }, "input": { "Company": [ "Apple", "Google" ] } }

Example — Fill a dataset's pending, stale, and failed cells: { "dataset_id": "ds_018f6a70-1234-7abc-89ab-0123456789ab" }

Example — Re-run one column on rows 10–12, even if filled: { "dataset_id": "ds_018f6a70-1234-7abc-89ab-0123456789ab", "columns": [ "CEO" ], "positions": [ 10, 11, 12 ], "force": true }

Workflow: Starts an async run. Call get_run_result with the returned run id and wait: 50 until status is 'success'; its output is the result.

Input Schema

NameRequiredDescriptionDefault
rowsNoWith dataset_id: only these rows (row_... ids). May be combined with positions. Default: every row.
forceNoWith dataset_id: re-run every cell in scope, whatever its state (the same as states naming every state).
inputNoRow source: inline columnar data
outputNoConfig source: a spec per output column (prompt, output_schema, tool)
promptNoConfig source: the task the agent follows for every row (requires attributes)
statesNoWith dataset_id: the cell states to run, e.g. ["not_found"] to research the not-found cells again. Default: pending, stale, failed. Not combined with force.
columnsNoWith dataset_id: only these output columns (by name). Default: every output column.
run_keyNoOptional idempotency key, unique per account. Becomes the run id ("run_<run_key>"), so it is limited to letters, digits, and . _ ~ - characters. A duplicate returns 409.
targetsNoWith dataset_id: several boxes of columns × rows in one run, e.g. CEO on rows 3-4 and HQ on rows 20-22. The scope is their union. Not combined with the flat columns / rows / positions.
positionsNoWith dataset_id: only the rows at these positions (from 1, as list_dataset_rows reports them). May be combined with rows.
attributesNoConfig source: the output column names, typed from their names (requires prompt). Max 20.
dataset_idNoRow source: a ds_... id. Fills the dataset's cells with its bound enrichment; no column config with it.
max_creditsNoCredit ceiling. Refused with 422 credit_cap_exceeded (nothing charged) when the estimate's maximum exceeds it.
webhook_urlNoURL to POST the results to when the run completes
enrichment_idNoConfig source: id of a saved enrichment (enr_...)
estimate_costNoValidate and price the request without running or charging anything; the 200 response is the credit estimate (EstimateCostResult).
allow_duplicate_inputNoWith enrichment_id — allow re-running rows already present in the enrichment

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.5

TDQS

A4.9/5.0
Behavior5/5

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

The annotations already declare the write/open-world/non-destructive profile, and the description adds important runtime behavior: async runs, polling with `get_run_result`, `estimate_cost`, webhooks, `run_key` duplicate 409s, credit-cap 422s, and legacy-mode responses. These are meaningful operational details beyond the annotation surface.

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 content is front-loaded and well organized around row source, config source, examples, and workflow. It is long, but the 17-parameter surface and nested config justify most of the length; some examples and schema-adjacent restatements could be trimmed.

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

Completeness5/5

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

There is no output schema, but the description fills that gap by explaining that the tool starts an async run, how to poll it, what dataset-fill results look like, and how to use `estimate_cost`. For a complex mutation tool with nested parameters and no output schema, this is complete enough for correct invocation.

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

Parameters5/5

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

Although schema coverage is already 100%, the description adds relational semantics that the schema alone only partly conveys: rows come from exactly one of `dataset_id` or `input`, column config is exactly one of the three ordered modes, and conditional row limits differ by mode. It also explains preferred workflow, default scope, and how `force`, `states`, `columns`, `rows`, and `positions` interact.

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?

The description immediately states the specific action: adding AI-researched columns to rows. It clearly distinguishes the two row sources (`dataset_id` vs. inline `input`) and explicitly routes dataset-preparation work to the sibling `build_dataset`. An agent can identify the tool's role 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 Guidelines5/5

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

It explicitly gives a preferred workflow, names alternatives like `build_dataset` and `update_dataset`, and explains when each configuration mode applies. It also states exclusions such as `output` being refused with `dataset_id` and clarifies default scope versus narrowed scope.

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

Deploy Server

Other Tools