Ragfeed

Estimate a monitor's cost (Beta)

ragfeed_monitor_estimate

Read-onlyIdempotent

(Beta) Work out what a planned monitor would cost, without creating it: credits per check, checks and credits in the next 30 days (estimates), the watched pages and the plan's limits (shortest interval, watched pages). Each check costs 1 credit per page read (pages that cannot be read are free), 2 credits per started 10 search results per query, and with a goal 2 credits per page or new search result judged by the KI-Bewertung. Call this before ragfeed_monitor_create with the same arguments and show the user the figures. Free of charge.

Input Schema

Name	Required	Description
`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	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.
`queries`	No	Web search queries to watch for new results (1 to 12). Needs a goal unless judge_enabled is false.
`schedule`	Yes	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
`name`	No
`error`	No	Only on failed calls (isError true).
`limits`	No	The plan's limits: planName, maxUrls, usedUrls, minIntervalMinutes, searchMinIntervalMinutes.
`created`	No	Always false: an estimate creates nothing.
`schedule`	No	When the monitor checks.
`creditsLeft`	No
`watchedUrls`	No
`judgeEnabled`	No
`termsAccepted`	No	The account accepted the monitoring terms (AGB Ziffer 2a).
`checksPerMonth`	No	Checks in the next 30 days.
`creditsPerCheck`	No	Most credits per check.
`judgeCreditsPerCheck`	No	Most extra credits per check for the KI-Bewertung.
`estimatedCreditsPerMonth`	No	Most credits in the next 30 days.
`estimatedCreditsPerMonthWithoutJudge`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 13, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the bar is lower; the description still adds that the monitor is not created, that figures are 30-day estimates, and the full credit-cost model including the free unreadable-page case.

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?

Effectively front-loaded, leading with the tool's purpose and the create-companion instruction, then the cost rules; it is dense but every clause carries pricing or sequencing information, with only mild overlap against the schema.

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?

An output schema exists, so return values need not be detailed, yet the description still enumerates the returned figures and the plan limits; combined with usage sequencing and the cost model, nothing needed 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 100%, so the baseline is 3; the description goes further by linking cost drivers to specific parameters (per-page reads for urls/crawl, per started 10 results for queries, goal-triggered KI-Bewertung judging), and surfaces the plan's shortest-interval limit that schedule depends on.

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?

Starts with a specific verb+resource combo ('Work out what a planned monitor would cost, without creating it') and immediately distinguishes itself from the create path, so an agent can separate it from ragfeed_monitor_create without opening either 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?

Explicitly instructs 'Call this before ragfeed_monitor_create with the same arguments and show the user the figures,' naming the alternative tool and the exact sequencing condition, and adds that the call is free of charge.

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?