Crank Protocol

cancel_perp_order

Destructive

Cancel a resting perp order on its venue (non-custodial).

jurisdiction: cancel is geo-gated too -- see place_perp_order.

idempotency_key (optional): a client-generated UUID. Retrying with the same key + same args replays the original result instead of re-cancelling the order. Reuse the SAME key across the build call and its signed_transaction completion call -- see place_perp_order; the two legs dedupe independently, so this never raises IDEMPOTENCY_CONFLICT.

signed_transaction / verify (two-phase execution): see place_perp_order. A cancel moves no position, so confirming the signature landed IS the verification -- no state re-read is declared.

venue_action (optional, completion leg only): see place_perp_order -- pass back the build leg's extra['venue_action'] (e.g. Jupiter's cancel-limit-order) so the relay route is the venue's own declared one instead of one inferred from the signed bytes.

simulate (optional): true = rehearse this call. The full gate stack (capability, kill switch, session signer, wallet policy, permission mode, soft launch, venue / compliance / token checks, fee quote) is evaluated read-only and returned as verdicts + would_execute, with a paper fill where one applies. Nothing is built, signed, broadcast or charged. Omitted = your wallet's default_simulate setting; false = execute.

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": {
      "wallet_address": "<wallet_address>",
      "order_id": "<order_id>"
    },
    "name": "cancel_perp_order"
  }
}

Input Schema

Name	Required	Description	Default
`ip`	No
`venue`	No
`verify`	No
`order_id`	Yes
`simulate`	No
`caller_id`	No
`jurisdiction`	No
`venue_action`	No
`wallet_address`	Yes
`idempotency_key`	No
`acknowledge_tier_b`	No
`signed_transaction`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 15, 2026

addedInput schema / properties / simulate

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

Changed1 schema field changedSep 23, 2026

addedInput schema / properties / venue_action

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

Changed2 schema fields changedAug 12, 2026

addedInput schema / properties / ip

Added value: +{
+  "default": "",
+  "type": "string"
+}

addedInput schema / properties / jurisdiction

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

Changed2 schema fields changedAug 11, 2026

addedInput schema / properties / signed_transaction

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

addedInput schema / properties / verify

Added value: +{
+  "default": true,
+  "type": "boolean"
+}

First observedJul 27, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and openWorldHint=true, but the description adds real value: non-custodial venue behavior, geo-gating via jurisdiction, idempotency replay semantics that avoid IDEMPOTENCY_CONFLICT, two-phase execution, and a detailed read-only simulate path (capability, kill switch, session signer, wallet policy, fee quote, etc.). Much of the deeper detail is deferred to place_perp_order, which slightly limits standalone transparency.

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?

Well-structured with backticked parameter headers and a front-loaded purpose sentence. It is fairly long and repeatedly defers to place_perp_order, which costs some efficiency, but the detail largely earns its place for a 12-parameter two-phase tool.

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?

An output schema exists, so return values need not be described, and the two-phase/simulate/idempotency mechanics are covered thoroughly. The main gap is the several undocumented parameters, but for the execution model the description is largely complete.

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 0%, so the description must carry the param burden. It documents the tricky params well (jurisdiction, idempotency_key, signed_transaction/verify, venue_action, simulate) but leaves venue, ip, caller_id, acknowledge_tier_b, wallet_address and order_id unexplained; acknowledge_tier_b in particular sounds important yet is undocumented.

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?

The opening sentence states a specific verb and resource: 'Cancel a resting perp order on its venue (non-custodial).' This cleanly distinguishes it from position-closing siblings like perp_close/close_perp_position and order-placement tools like place_perp_order without needing the schema.

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?

It gives clear situational guidance for each optional parameter: when to supply an idempotency_key, when to use two-phase verify/signed_transaction, when to pass venue_action (completion leg only), and what simulate does. However it never explicitly contrasts canceling with alternatives such as perp_modify or perp_close; the differentiation is left implicit.

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

All Crank Protocol 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?