Skip to main content
Glama
riveterhq

Riveter MCP Server

Official
by riveterhq

Create monitor

create_monitor

Schedules a dataset monitor to refill output columns daily, weekly, or monthly, compare each run with the previous one, and POST results or only changes to a webhook.

Instructions

create monitor

Create a monitor: a schedule that fills a dataset's output columns again daily, weekly, or monthly, compares each cell with the previous run, and can POST results (or only changes) to a webhook. Pass dataset_id and optionally columns (output column names; every one when omitted); the rows are the dataset's, no input. Creation is free; every run charges the fill price. estimate_cost: true prices one run. help → monitors.

Example — Daily monitor on a dataset, webhook only on changes: { "dataset_id": "ds_018f5b60-1234-7abc-89ab-0123456789ab", "columns": [ "Headcount", "Latest funding round" ], "cadence": "daily", "hour": 9, "minute": 0, "timezone": "UTC", "alert_rule": "on_diff", "output_format": "include_diffs", "webhook_url": "https://your-server.com/webhook" }

Example — Weekly monitor, every output column, results every run: { "dataset_id": "ds_018f5b60-1234-7abc-89ab-0123456789ab", "cadence": "weekly", "day_of_week": 1, "hour": 7, "minute": 30, "timezone": "America/New_York", "webhook_url": "https://your-server.com/webhook" }

Workflow: Creates a scheduled monitor. Check it with get_monitor, pause it with update_monitor (enabled: false), and list its runs with list_monitor_runs.

Input Schema

NameRequiredDescriptionDefault
hourYesHour of the day to run
inputNoMonitors on a legacy enrichment only — fixed rows every scheduled run enriches (same shape as enrich input). Refused on a dataset monitor; its rows are the dataset's.
minuteYesMinute of the hour to run
cadenceYesHow often the monitor runs
columnsNoOutput column names each run fills. Omit for every output column, including ones added later.
timezoneYesTimezone (e.g. 'UTC', 'America/New_York')
alert_ruleNoWhen the webhook fires — every run, only when a monitored cell changed since the previous run, or never (default each_run)
dataset_idNoThe dataset to fill again on the schedule (ds_...). One of dataset_id / enrichment_id is required.
day_of_weekNoDay of the week (0=Sunday, required for weekly)
max_creditsNoCredit ceiling. Refused with 422 credit_cap_exceeded (nothing charged) when the estimate's maximum exceeds it.
webhook_urlNoURL to receive results each scheduled run
day_of_monthNoDay of the month (required for monthly)
enrichment_idNoInstead of dataset_id — the enrichment bound to the dataset (enr_...). A legacy enrichment's id creates a monitor on it over fixed `input` rows (legacy API docs); the response carries `legacy`.
estimate_costNoValidate and price the request without running or charging anything; the 200 response is the credit estimate (EstimateCostResult).
output_formatNoinclude_diffs adds `previous_value` and `changed` to every cell of the run's output and webhook payload (default current_only)
run_immediatelyNoAlso run the monitor immediately after creation (a paid run)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.5

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations, the description discloses the billing model (creation free, every run charged, estimate_cost prices one run), the comparison behavior between runs, the webhook firing modes, and the fact that dataset monitors use the dataset's rows rather than input. This is substantial behavioral context for a mutating, non-idempotent tool.

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 description is front-loaded with the core definition and then uses examples and a workflow sentence, which is appropriate for a 16-parameter creation tool. It is slightly long and opens with a redundant lowercase 'create monitor', but the examples and structure earn their place.

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?

Given the high parameter count, nested input object, and absence of an output schema, the description is complete enough to call the tool correctly. It covers the schedule, cost model, webhook behavior, dataset versus legacy enrichment distinction, examples, and follow-up workflow while relying on the schema for exhaustive parameter details.

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 schema already documents each parameter. The description adds practical meaning through examples and clarifications such as omitting columns meaning all output columns, dataset monitors not using input, and estimate_cost returning a price without running. It does not add prose semantics for every parameter, but it improves the most important ones.

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 states a specific verb and resource, then explains the monitor's distinctive behavior: scheduled re-filling of dataset output columns, cell-by-cell comparison with the previous run, and optional webhook posting. It also names the sibling tools used to inspect, pause, and list runs, making it clearly distinguishable from create_enrichment or update_monitor.

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?

It gives clear post-creation workflow guidance with get_monitor, update_monitor, and list_monitor_runs, and explains that dataset_id is the normal path while input is for legacy enrichment monitors. However, it does not explicitly state when to choose create_monitor over other creation tools or when not to use it.

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