Skip to main content
Glama

delete_page

DestructiveIdempotent

Permanently remove a wiki page by ID, including its database record and on-disk markdown projection, only when the user explicitly requests deletion.

Instructions

Delete a page by id only when the user explicitly asks to remove it. Destructive — removes both the DB row and the on-disk md projection. To refresh an existing page while preserving its page_id and version history, use write_page. Pages without sources can be re-derived by running /distill again on the same scope.

Input Schema

NameRequiredDescriptionDefault
page_idYesPage id (e.g. 'page_abc' or legacy 'concept_abc'). Get it from distill output.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.19.3

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true, but the description goes beyond them by disclosing exactly what is destroyed ('both the DB row and the on-disk md projection') and what recovery looks like ('Pages without sources can be re-derived by running /distill again'). That is real behavioral context, not a restatement of structured hints.

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?

Three sentences with zero waste: the action and its guard clause come first, the destruction scope second, the alternative third. No sentence repeats the title or annotations.

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 single-parameter destructive tool with no output schema, the definition covers the safety profile, the physical scope of deletion, the recovery path, and the correct sibling alternative. An agent has everything needed to decide whether and how to call it.

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?

There is one parameter, page_id, and the schema already documents it fully at 100% coverage, including the legacy 'concept_abc' format and where to obtain it from distill output. The description adds only the 'by id' framing, so the schema is doing the heavy lifting and baseline 3 is appropriate.

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 a specific verb and resource ('delete a page by id') and immediately distinguishes the operation from the sibling write_page by explaining that write_page refreshes while preserving page_id and history. An agent can tell the two apart 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?

Gives an explicit precondition ('only when the user explicitly asks to remove it') and names the alternative action ('to refresh an existing page, use write_page'). It even covers the edge case of re-deriving source-less pages via /distill, leaving nothing to inference.

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