agent-passport-system-mcp

Withdraw Provisional Statement

aps_withdraw_provisional

Read-onlyIdempotent

Withdraw a provisional statement by providing the author's signature over the withdrawal payload. Promoted statements cannot be withdrawn.

Instructions

Commitment boundary: author withdraws their own provisional statement. Already-promoted statements cannot be withdrawn. Caller must supply the author's signature over the withdrawal payload (canonicalize({action:'withdraw', statement_id})).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "statement": "<statement>"
    },
    "name": "aps_withdraw_provisional"
  }
}

Input Schema

Name	Required	Description
`statement`	Yes	ProvisionalStatement to withdraw
`author_signature`	No	Hex Ed25519 signature. If omitted, provide author_private_key and the tool will sign for you.
`author_private_key`	No	If provided, tool signs the withdrawal payload with this key.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv4.0.0Aug 1, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

removedInput schema / additionalProperties
```
Removed value: -false
```
addedInput schema / required
```
Added value: +[
+  "statement"
+]
```

Addedv2.8.0May 1, 2026

TDQS

B3.3/5.0

Behavior1/5

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

The description asserts a state-changing action ('author withdraws their own provisional statement') and a signed withdrawal payload, while the annotations declare readOnlyHint=true (no environment modification). A withdrawal changes the statement's status, so the structured safety hint and the prose conflict. The added commitment-boundary and author-signature context is useful, but the contradiction is disqualifying.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loading boundary semantics, then the promotion exclusion, then the signing requirement. Every clause carries information, though the jargon opener 'Commitment boundary:' is slightly opaque as a lead.

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

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers the action, the author-only precondition, the promotion exclusion, and the signing payload – most of what is needed for a 3-parameter tool. With no output schema and a contradicted annotation, it still leaves the tool's actual effect (persisted withdrawal vs. returned artifact) and return value unspecified.

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

Parameters4/5

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

Schema coverage is 100%, so the three parameters are already documented and the baseline is 3. The description earns a bump by stating who must sign (the author) and the exact payload to canonicalize (canonicalize({action:'withdraw', statement_id})), details absent from the schema's generic 'Hex Ed25519 signature' text.

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?

Names a specific verb (withdraw) and resource (provisional statement), scopes it to the author's own statement, and draws a line against promotion with 'already-promoted statements cannot be withdrawn.' An agent can distinguish it from aps_promote_statement, though that sibling is not named explicitly.

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 a clear precondition (caller must be the author) and an explicit when-not condition (promoted statements cannot be withdrawn). It stops short of naming the alternative tool to use when withdrawal is not applicable, so routing to siblings is left implicit.

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

Deploy Server