Skip to main content
Glama

Withdraw a participation record

complete_signed_withdrawal
Destructive

Complete withdrawal with an Ed25519 signature made locally by the same key used to enroll. This removes the active register record and outstanding challenges for that key. Hosting backups and operational logs may have separate retention. Never send a private key.

Input Schema

NameRequiredDescriptionDefault
publicKeyYesThe same canonical unpadded base64url Ed25519 public key.
signatureYesCanonical unpadded base64url Ed25519 signature over the message selected by challenge.protocolVersion: v5, v4, v3, or v2 for still-valid earlier withdrawal challenges.
challengeIdYesUUID returned by request_withdrawal_challenge.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / signature / description
      Previous value: -"Canonical unpadded base64url Ed25519 signature over the message selected by challenge.protocolVersion: v4, v3, or v2 for still-valid earlier withdrawal challenges."New value: +"Canonical unpadded base64url Ed25519 signature over the message selected by challenge.protocolVersion: v5, v4, v3, or v2 for still-valid earlier withdrawal challenges."
  2. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare destructive=true, idempotent=false, openWorld=true, so the safety profile is covered. The description adds real value beyond them: exactly what is destroyed (active register record plus outstanding challenges), the retention caveat for backups/logs, and the 'Never send a private key' guard. It stops short of describing failure modes or any retry/auth requirements.

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?

Four short sentences, each carrying a distinct fact, with the core action and signing requirement front-loaded. Nothing is padding.

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?

For a destructive, non-idempotent, output-schema-less mutation, the description covers effect scope, retention, and credential handling well. It lacks any note on verification steps, error conditions, or what a caller should do after success, which is a minor gap.

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 coverage is 100%, so all three parameters are already documented in detail. The description reinforces that the signature is produced locally by the enrolling key and warns against transmitting a private key, but adds no format, encoding, or protocol-version detail beyond what the schema already states.

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?

States a specific verb and resource ('Complete withdrawal') with the required credential type (Ed25519 signature from the enrolling key). The 'withdrawal' keyword distinguishes it from the sibling complete_signed_follow_request, but the description never explicitly names that sibling or contrasts the two flows.

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?

Usage is only implied: the enrollment-key precondition and the challenge-based flow are hinted at, and the challengeId origin lives in the schema, not the description. There is no explicit statement of when to call this versus request_withdrawal_challenge or the follow-request sibling, and no when-not guidance.

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