Skip to main content
Glama

Delete status page

delete_status_page
DestructiveIdempotent

Permanently deletes a status page by UID or slug, removing it and all its sections and resources from the API and public site. There is no undelete, so use enabled:false to hide a page temporarily instead.

Instructions

Soft-delete a status page by UID or slug: the page disappears from the API and the public site, taking its sections and resources with it, and its uploaded brand assets are deleted. There is no undelete (permanent, not reversible) — use update_status_page with enabled:false to take a page down without destroying it. Use delete_status_page_section or delete_status_page_resource to remove part of a page instead. Requires the mcp scope (mcp:read tokens are refused) and at least the user role in the organization.

Input Schema

NameRequiredDescriptionDefault
identifierYesStatus page UID or URL-friendly slug, e.g. "public".

Output Schema

NameRequiredDescriptionDefault
deletedYesAlways true on success.
identifierYesThe identifier that was deleted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.42.0
    • addedInput schema / properties / identifier / maxLength
      Added value: +2048
    • addedInput schema / properties / identifier / minLength
      Added value: +1
  2. Changed2 schema fields changedv0.41.0
    • addedInput schema / additionalProperties
      Added value: +false
    • addedOutput schema / additionalProperties
      Added value: +false
  3. Changed1 schema field changedv0.38.5
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "deleted": {
      +      "description": "Always true on success.",
      +      "type": "boolean"
      +    },
      +    "identifier": {
      +      "description": "The identifier that was deleted.",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "deleted",
      +    "identifier"
      +  ],
      +  "type": "object"
      +}
  4. First observedv0.32.1

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond annotations by disclosing that destruction is permanent with no undelete, that sections/resources are removed, and that uploaded brand assets are deleted. It also states the required mcp scope and minimum user role, which are critical operational constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The destructive consequence and identifier are front-loaded, followed immediately by the safer alternative and partial-deletion alternatives. Despite its length, every sentence carries decision-relevant information for a destructive operation.

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 destructive annotations, a fully described single parameter, an output schema, and the tool's cascading deletion behavior, the description covers the important operational and safety context. Auth requirements and irreversibility are included, leaving no material gap for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already documents the single identifier parameter at 100% coverage, including UID-or-slug semantics and an example. The description restates that identifier may be a UID or slug but adds no further syntax, validation, or edge-case guidance beyond 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?

States the specific action (soft-delete a status page) and identifier types (UID or slug), plus the cascade scope. It clearly differentiates this destructive full-page deletion from sibling tools that delete only sections or resources.

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 says to use update_status_page with enabled:false instead when the goal is merely taking a page down without destroying it. It also directs partial removal to delete_status_page_section or delete_status_page_resource, so the agent has clear alternatives.

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