Skip to main content
Glama
bim-ba

ycli

by bim-ba
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Delete Wiki page

wiki_pages_delete
Destructive

Delete a wiki page by numeric id, optionally removing all child pages. Save the returned recovery token to undo the deletion later.

Instructions

Delete a wiki page by numeric id (DELETE /pages/{id}).

KEEP the returned recovery_token — it is the only handle to undo the delete (redeem it with recovery_recover). Deleting removes the page's descendants' anchor too, so double-check the id (pages_get_by_id) before calling.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
page_idYesNumeric id of the page to delete.
recursiveNoAlso delete every page under it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.122.1
    • addedInput schema / properties / recursive / anyOf
      Added value: +[
+  {
+    "type": "boolean"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedInput schema / properties / recursive / default
      Previous value: -falseNew value: +null
    • removedInput schema / properties / recursive / type
      Removed value: -"boolean"
  2. First observedv0.67.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and non-idempotency, but the description adds crucial behavior not visible there: the returned recovery_token is the only undo handle, and deletion removes descendants' anchors. This is exactly the kind of consequence disclosure annotations cannot carry.

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 tightly-written sentences, front-loaded with the operation, then the critical recovery-token caveat, then the pre-call verification advice. Every sentence earns its place with no filler.

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 no output schema, the description compensates by explaining the return value (recovery_token) and its significance, plus the ancestor/descendant side effects. Nothing needed to call this destructive tool safely is missing.

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?

Schema description coverage is 100%, so both page_id and recursive are already documented in the schema, making the baseline 3. The description's mention of descendant anchors hints at the recursive cascade but adds no syntax or value constraints beyond what the schema states.

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+resource ('Delete a wiki page by numeric id') and even names the underlying route, distinguishing it clearly from siblings like wiki_pages_update or wiki_pages_move. It also names related tools (recovery_recover, pages_get_by_id) so the agent understands the surrounding workflow.

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

Usage Guidelines4/5

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

Gives clear pre-call guidance ('double-check the id (pages_get_by_id) before calling') and explains the undo path via recovery_recover, which routes the agent to the right sibling post-delete. It stops short of explicit when-not-to-use guidance, so it is clear context without full exclusions.

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

Deploy Server

Other Tools