Skip to main content
Glama
riveterhq

Riveter MCP Server

Official
by riveterhq
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Create enrichment

create_enrichment

Define a data enrichment task with a prompt, output columns, and budget, and create an empty dataset to fill with row-by-row results.

Instructions

create enrichment

Create an enrichment (no run, free) and the empty dataset it fills, bound to it and in the app at app_url. A recipe: prompt (the task), output columns (names, or { name, prompt, output_schema, tool } — tool: "<list_tools name>" pins a tool: one call per row, arguments chosen by the agent, result is the cell; help with output_schema / pinned_columns), optional input_columns, budget (credits per row, default 1.5 per output column; follows column adds / removes unless budget_locked), only_tools / additional_tools (list_tools). Prefer prompt alone: the output columns (one typed column per fact asked for), name, and input columns are written from it; the response shows them. Then add_dataset_rows to the dataset_id and enrich with it (preferred), or enrich with enrichment_id + input for a one-off. dataset_id alone answers a dataset's own enrichment as { id, name, app_url, dataset_id } (422 without output columns; add them with update_dataset).

Example — Save a recipe — three columns, one typed: { "name": "Company basics", "prompt": "Research each company from its name and website.", "input_columns": [ "Company", "Website" ], "output": [ "CEO", { "name": "Employee count", "prompt": "Current headcount as an integer", "output_schema": { "type": "integer", "minimum": 0 } }, { "name": "Summary", "prompt": "Two sentences on what the company sells and to whom" } ], "budget": 4 }

Example — The recipe written from the prompt — columns, name, and input columns: { "prompt": "Research each company from its name and website: the CEO, employee count, latest funding round date and amount, and whether it is hiring." }

Example — A dataset's own enrichment: { "dataset_id": "ds_018f6a70-1234-7abc-89ab-0123456789ab" }

Input Schema

NameRequiredDescriptionDefault
nameNoRecipe: display name
budgetNoRecipe: credits the row agent may spend per row. Default 1.5 per output column.
outputNoRecipe: the columns to fill; a plain string is a name whose type is inferred. Omit it and the columns are written from the prompt, one per fact it asks for, each typed.
promptNoRecipe: the task prompt the row agent reads for every row. Required without dataset_id.
dataset_idNoAlone: a dataset's id (ds_...); answers its own enrichment. Not with the fields below.
only_toolsNoRecipe: exactly these tools (GET /tools). Replaces the default set.
budget_lockedNoRecipe: true keeps the budget as set when output columns are later added or removed; false lets it move by 1.5 per column.
input_columnsNoRecipe: the headers rows must carry, the dataset's input columns. Omit for any (one `Input` column), or, without output, for the ones the prompt implies.
additional_toolsNoRecipe: the default tools plus these (GET /tools; some need enabling on the account or a linked key).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.5

TDQS

A4.6/5.0
Behavior4/5

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

Annotations only say not-readOnly, not-destructive, not-idempotent; the description adds meaningful behavior: no run is triggered, no credits are spent, an empty dataset is created and bound, a 422 is returned when `dataset_id` alone has no output columns, and budget auto-adjusts by 1.5 credits per column unless `budget_locked`. It doesn't cover permissions or what the response looks like beyond the id/name/app_url tuple, keeping it below 5.

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 opening line and the 'Prefer prompt alone' directive are front-loaded, and the three examples are labeled and useful. The first paragraph is a dense run-on packing ~8 distinct rules into one block, which costs some readability.

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?

Covers both call modes, the sequencing with `add_dataset_rows`/`enrich`, the error path, budget semantics, and the tool-pinning feature, backed by three concrete payload examples. For a 9-parameter tool with no output schema, nothing an agent needs to invoke it correctly is missing.

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 already 100%, so the baseline is 3; the description still adds cross-parameter meaning — the string shorthand for `output`, `tool: "<list_tools name>"` semantics ('one call per row, result is the cell'), budget default and its movement on column add/remove, and the `only_tools` vs `additional_tools` relationship. This goes beyond the per-property schema text.

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 plus its scope: creating an enrichment that does NOT run and is free, along with the empty dataset it fills. It also distinguishes the two modes (recipe creation vs. `dataset_id`-only lookup of a dataset's own enrichment), so an agent can tell it apart from `enrich`, which actually runs.

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?

Gives explicit routing: create here, then `add_dataset_rows` on the returned `dataset_id` and `enrich` with it (marked preferred), versus `enrich` with `enrichment_id` + `input` for a one-off. It also says 'Prefer `prompt` alone' and names `update_dataset` for the 422 case with no output columns.

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