FlareWarden

Plan monitoring for websites

plan_site

Use this when the user wants FlareWarden to monitor a website or API they run, or up to 50 of them at once. Returns a plan: what each site runs on (hosting, CDN, cloud regions, payments and other services, found from its DNS and page), which automatic page checks hold on it now, and the decisions to put to the user with recommendations and their cost in monitors. Saves the plan and changes nothing in the account; call again with the plan id and the user's answers. Not for adding a check to a site already monitored: use plan_dependency, plan_content_check or plan_cron_monitor.

Input Schema

Name	Required	Description
`url`	No	The site's URL, such as https://acme.com, for one site.
`name`	No	The site's name, for one site; the host name by default.
`urls`	No	Up to 50 site URLs, for adding many at once.
`group`	No	A group to put the sites in.
`answers`	No	The user's answers, by decision id: services, checks, interval, group, anomaly, fit, exclude_sites, and deps.<service>.* for a service's configuration. Also timeout, never asked: the seconds each site's checks wait for an answer (5, 10, 15 or 30; 10 unless given), longer for a page that is slow but up.
`plan_id`	No	An earlier plan_site plan's id, to read it again or answer its decisions.
`from_workspace`	No	For one site only: services the site uses that are visible in the user's own workspace and not from outside, such as its infrastructure config, package manifests or environment variable names. Each is a service by its FlareWarden catalogue name, the regions it runs in as region ids, and the file it was found in; a service the catalogue does not list also needs its kind and status page. Names, regions, file paths and status pages only: no values, secrets or file contents. They are pre-selected in the plan and labelled as the assistant's; the user still confirms.
`component_query`	No	Searches a dependency's long component list (more than 50) by name.
`accept_recommended`	No	True when the user asked FlareWarden to choose: every open decision that has a recommendation takes it.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Adds real context beyond the annotations: it persists a plan but changes nothing in the account, discovery is done from the site's DNS and page (explaining the openWorldHint), and the whole flow is two-phase. It does not discuss latency, failure modes, or what happens to a saved plan that is never answered, which keeps it off a 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?

Front-loads the trigger, then the return shape, then the side-effect contract, then the exclusion. The sentences are long and clause-heavy, but each carries distinct information; no filler or restatement of the name.

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?

With 9 params, nested objects, no output schema and non-read-only annotations, the description supplies what is otherwise missing: the contents of the returned plan, the two-step confirm loop, and the guarantee that nothing in the account is mutated. An agent can call it correctly and know what to do next.

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, but the description adds model-level meaning: url/urls are the one-vs-many split, plan_id drives the re-read/answer round trip, answers map to decision ids, and from_workspace entries are pre-selected and attributed to the assistant pending user confirmation. That goes beyond per-field text in the schema.

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?

Names a specific verb and resource ('plan monitoring for a website or API', up to 50 at once) and immediately scopes it against the sibling family that handles single checks on already-monitored sites. An agent can distinguish plan_site from plan_dependency/plan_content_check/plan_cron_monitor 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 Guidelines5/5

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

Gives an explicit trigger ('when the user wants FlareWarden to monitor a website or API they run'), an explicit anti-trigger ('Not for adding a check to a site already monitored'), and names the three alternative tools to use instead. It also states the follow-up pattern: call again with the plan id and the user's answers.

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

All FlareWarden 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?