Permanently delete a status page. This cannot be undone, and any public URL it had stops working immediately. The monitors on the page are NOT affected — they keep running and alerting exactly as before; only the shared view of them is removed. To stop sharing without losing the page, set visibility to 'private' with update_status_page instead.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Status page UUID, from list_status_pages. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already mark destructiveHint=true, the description adds crucial behavioral details: the deletion cannot be undone, public URLs stop working immediately, and monitors are not affected. This goes well beyond the annotation and gives the agent a full picture of side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with every sentence contributing distinct value: the action, the irreversibility/URL impact, the non-effect on monitors, and the alternative path. There is no filler or repetition that weakens the message.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter destructive action with no output schema, the description fully covers what the tool does, its consequences, what it does not affect, and the alternative to achieve a less destructive outcome. Nothing critical is missing for correct invocation and decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, id, is already fully documented in the schema with 'Status page UUID, from list_status_pages.' The description does not add further parameter-level meaning, but schema coverage is 100%, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Permanently delete a status page') and immediately clarifies the permanent, irreversible nature of the operation. It clearly differentiates this destructive action from update_status_page by stating what not to do if the intent is merely to stop sharing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use context: permanent deletion is intended, and if the user only wants to stop sharing without losing the page, they should use update_status_page with visibility set to 'private'. This is a clear routing instruction with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Tools are organized by clear resource domains, and the long descriptions carefully separate similar reads. The main ambiguity is create_monitor's upsert behavior overlapping with update_monitor, and list_incidents vs list_open_incidents could be confused from names alone.
Almost every tool uses verb_noun snake_case with a consistent CRUD vocabulary like create_, list_, get_, update_, and delete_. Minor deviations exist: get_alert_templates is really a list operation, and discover_monitors_reconcile is an awkward verb-object-verb construction.
Thirty-six tools is a heavy surface for an agent to navigate, even for a full monitoring platform. Most tools are individually purposeful, but the count exceeds the range where an agent can quickly scan and select, and the set would be easier to handle if split across domains.
Coverage is strong: monitors, destinations, agents, status pages, API keys, routes, alert templates, incidents, run history, discovery, and Terraform export all have read and lifecycle operations. Minor gaps remain, such as no explicit single-incident view and no acknowledgment/resolution action beyond notes, but core workflows have no dead ends.
