Skip to main content
Glama

Remove a fmrl.site page

fmrl_delete
DestructiveIdempotent

Remove a published page by its id or any fmrl.site link. The page then returns 410 permanently, and only pages owned by the key can be deleted.

Instructions

Remove a page this key published, by id or any fmrl.site link. Only call it when the person asked to remove the page; to hide it instead, fmrl_set_visibility can make it private. There is no undo tool: the page answers 410 from then on. A page this key doesn't own fails and stays as it is.

Input Schema

NameRequiredDescriptionDefault
idYesThe page id, or any fmrl.site link to the page.

Output Schema

NameRequiredDescriptionDefault
idYes
urlYes
removedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.17.8
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedInput schema / properties / id / description
      Previous value: -"A document id or any fmrl.site URL for it."New value: +"The page id, or any fmrl.site link to the page."
  2. First observedv0.17.6

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the destructiveHint annotation by spelling out the concrete consequence: no undo tool exists and the page answers 410 permanently. The non-ownership failure mode is also disclosed, telling the agent the call can fail safely rather than partially destroy something.

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, front-loaded with what it does, then when to use it, then what irreversibility means. Every sentence carries distinct information and none is 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?

For a destructive one-parameter tool with annotations and an output schema, the description covers purpose, routing to an alternative, irreversibility, and failure behavior. Nothing an agent needs before invoking it is missing, and return values are left to the output schema.

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% and the schema already documents that the single id parameter accepts a page id or any fmrl.site link, so the description restates rather than extends it. Baseline 3 is appropriate for a one-parameter tool whose schema does the work.

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 ("Remove") and resource ("a page this key published") plus accepted identifier forms (id or any fmrl.site link). The ownership qualifier scopes it precisely and separates it from siblings that act on other keys' pages.

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 gate ("Only call it when the person asked to remove the page") and names the alternative for the adjacent intent (fmrl_set_visibility to make it private instead). It also states what happens when the precondition fails: a page this key doesn't own fails and is left untouched.

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