Ragfeed

Change, pause or resume a monitor (Beta)

ragfeed_monitor_update

DestructiveIdempotent

(Beta) Change a monitor's settings, or pause (status paused: no checks, no credits) and resume it (status active). Only the given settings change. urls replaces the single pages, crawl_url the website, queries the search; an empty list or text removes that part. An empty goal removes the goal and the KI-Bewertung. Get the user's OK before a change that raises the cost (more pages, a shorter interval, a goal); the answer shows the new credits per check and per month. Also confirm with the user before removing pages or the website (their stored versions are deleted) and before a new webhook or new e-mail recipients (the results then go elsewhere).

Input Schema

Name	Required	Description
`id`	Yes	Monitor id (from ragfeed_monitor_list or ragfeed_monitor_create).
`goal`	No	What counts as a relevant change, in the user's words, e.g. 'price changes or new products'. Switches on the KI-Bewertung: changed pages and new search results are judged against it.
`name`	No	New name of the monitor.
`urls`	No	Single pages to watch (full http(s) addresses).
`email`	No	E-mail (Meldung) to the account's own address after checks that found changed, new, removed or newly unreadable pages (default true; a page that stays unreadable is reported once). With a goal, pages the KI-Bewertung judged not relevant trigger no e-mail.
`status`	No	paused stops the scheduled checks; active resumes them.
`queries`	No	Web search queries to watch for new results (1 to 12). Needs a goal unless judge_enabled is false.
`schedule`	No	When to check: a phrase such as 'every 30 minutes', 'hourly', 'every 6 hours', 'daily', 'daily at 8:00', 'daily at 9am', 'weekly', 'every monday at 8:00', or in German 'alle 30 Minuten', 'stündlich', 'alle 6 Stunden', 'täglich um 8:00', 'wöchentlich', 'jeden Montag um 8 Uhr'; or a 5-field cron expression such as '0 8 * * 1-5'. The plan sets the shortest allowed interval (ragfeed_monitor_estimate shows it).
`timezone`	No	IANA time zone of the schedule (default Europe/Berlin).
`crawl_url`	No	Start page of a whole website to watch; its pages are found anew on every check.
`crawl_limit`	No	Most pages of the website per check (default 50 or the plan's smaller limit); each counts as a watched page.
`max_results`	No	Search target: most results per check over all queries (default 10).
`webhook_url`	No	Also send the results to this endpoint URL as webhooks (events monitor.page and monitor.check.completed, signed with the account's webhook secret).
`exclude_paths`	No	Website target: skip URL paths matching these regular expressions.
`include_paths`	No	Website target: only URL paths matching these regular expressions.
`judge_enabled`	No	false keeps the goal but switches the KI-Bewertung off.
`search_window`	No	Search target: how recent results must be (default 24h).
`retention_days`	No	Days check results are kept (default 30).
`exclude_domains`	No	Search target: no results from these domains.
`include_domains`	No	Search target: only results from these domains.
`email_recipients`	No	Up to 5 further e-mail addresses besides the account's own; each gets a confirmation mail first and receives nothing until it confirms.
`email_include_diffs`	No	Put short excerpts of the changes into the e-mails.

Output Schema

Name	Required	Description	Default
`error`	No	Only on failed calls (isError true).
`monitor`	No	A monitor.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 13, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true and idempotentHint=true, but the description adds material context the annotations cannot convey: which stored data is deleted (page/website stored versions), that cost-raising edits are previewed via new credits per check and per month, that an empty list or text removes that target, and that new webhook/e-mail targets redirect results. This goes well beyond the structured fields.

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?

Purpose is front-loaded in the first clause, and the dense clauses about replacement, removal, and confirmation are all load-bearing. It is long but not padded; the run-on sentence structure makes it slightly harder to scan than an ideal definition.

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?

For a 22-parameter, destructive, open-world mutation with an output schema already present, the description covers the gaps that matter: merge/removal semantics, cost preview, irrecoverable deletions, and redirected results. Nothing an agent needs before calling it 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 100%, so baseline is 3, but the description adds non-obvious merge semantics absent from the schema: 'urls replaces the single pages, crawl_url the website, queries the search', and that an empty list/text or empty goal removes that part (including the KI-Bewertung). That replace-vs-remove behavior is genuinely load-bearing for a 22-parameter patch tool.

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 the specific operations (change settings, pause, resume) on a specific resource (monitor), and the parenthetical '(Beta)' plus 'Only the given settings change' immediately distinguishes it from ragfeed_monitor_create and ragfeed_monitor_delete. An agent can route to it without opening any 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 explicit conditionality that other tools lack: pause semantics ('no checks, no credits'), the rule that 'only the given settings change', and three named cases requiring user confirmation (cost-raising changes, removing pages/website, new webhook or e-mail recipients). It stops short of naming which sibling to use instead for related tasks (create/get/delete), so it is not a full 5.

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

All Ragfeed 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.

Resources

Need Help?