Skip to main content
Glama

Delete Page

page.delete
DestructiveIdempotent

Delete a page. This always asks the user first. page.restore brings it back with its content.

Input Schema

NameRequiredDescriptionDefault
pageIdYes

Output Schema

NameRequiredDescriptionDefault
nameYes
pageIdYes
deletedYes
restoreWithYesThe tool that brings it back, with the same pageId

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description still adds genuinely new behavior: the tool always prompts the user for confirmation, so the agent should not expect a silent destructive call, and the deletion is recoverable via restore. It omits how children/backlinks are affected and whether there's a permanent-purge window.

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 short sentences, zero padding, and the central fact (user confirmation) is front-loaded right after the purpose statement.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/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 explained, and the description covers the two things an agent most needs for a destructive call: that a confirmation prompt intervenes and that the effect is reversible. Slightly short of complete because blast radius (subpages, references) and the window for restore are unstated.

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

Parameters2/5

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

There is one required parameter, pageId, with 0% schema description coverage — the schema gives only type and a positive-integer bound. The description says nothing about what pageId accepts (page ID vs. slug, where to obtain it), so the low-coverage case is not compensated.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

A specific verb (delete) plus resource (page) with no ambiguity, and it points at page.restore as the inverse so the agent can tell the pair apart. It doesn't address other near-neighbors like item.archive, but the core purpose is unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

"page.restore brings it back with its content" implies that restore is the recovery path and that deletion is reversible, which gives some context for choosing between them. However there is no explicit when-to-use/when-not guidance (e.g. archive vs delete) — the guidance is implied rather than stated.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources