Cape Partners Exchange

Withdraw a declaration from the exchange

withdraw_manifest

Destructive

Use this when the user wants to UN-SAY a declaration they already published — the scope was wrong, the mandate changed, or they simply no longer want to be on the exchange. Identified by the key (msgid) they already hold, so nothing new is asked of them. It is NOT a delete: the exchange marks that key so the thread stops answering and accepts no further replies, records the withdrawal with any reason given, and keeps both in its ledger; the user's OTHER threads are untouched. Anything already introduced through it is two-sided and stays with the desk. A new declaration is a NEW key (publish_manifest without key). The call is staged: a dry run sends nothing, and the confirmed call is bound to the exact payload that dry run returned. Call once with dry_run=true to get the exact payload and a confirmation_token; call again with the same arguments plus that token to send. A token that does not match the payload is refused and nothing is sent.

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": {
      "request_id": "<request_id>",
      "key": "<key>"
    },
    "name": "withdraw_manifest"
  }
}

Input Schema

Name	Required	Description
`key`	Yes	The msgid (or answer_key) of the declaration being withdrawn — from the receipt that created it.
`reason`	No	Optional reason in the user's own words, recorded with the withdrawal.
`dry_run`	No	true returns the exact withdrawal and a confirmation_token, and withdraws nothing.
`request_id`	Yes	Your own idempotency key for this withdrawal; quote it as the receipt.
`confirmation_token`	No	The token from the dry run, for the confirmed withdrawal.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Goes well beyond the annotations: explains that the key is marked so the thread stops answering, that the withdrawal and reason persist in the ledger, that other threads are untouched, and that already-introduced two-sided items stay with the desk. It also discloses the staging mechanism and that a mismatched token is refused with nothing sent. The only small gap is confirmation of what the successful receipt contains, though request_id is indicated as the receipt.

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?

Front-loads the when-to-use, then the semantic distinction from delete, then the two-call protocol. Every sentence carries information, though the ledger/thread sentence is dense and the description sits at the long end for a 5-parameter tool.

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, irreversible-looking operation with no output schema, the description supplies the safety semantics, the side effects, the alternatives, and the exact invocation protocol. Nothing needed to call it correctly is missing.

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 baseline is 3, but the description adds real meaning: it clarifies that `key` is a value the user already holds (nothing new is asked), and it explains the relationship between dry_run, confirmation_token, and payload matching, which is a cross-parameter contract the schema only lists separately.

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?

Specific verb-plus-resource ('UN-SAY a declaration they already published') with an explicit identity mechanism (the msgid the user already holds). It directly contrasts itself with 'delete' and with the sibling publish_manifest, so an agent can distinguish it from every neighbouring tool.

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 concrete triggers (wrong scope, changed mandate, no longer want to be on the exchange), an explicit non-use case ('It is NOT a delete'), and routes new declarations to publish_manifest without a key. The dry-run-then-confirm sequence is spelled out as the required calling pattern.

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

All Cape Partners Exchange tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?