Crank Protocol

create_execution_intent

Destructive

Create a propose-only execution intent; returns an approval URL to hand to the user.

submit_mode (optional): omitted/"public" is unchanged and is named in summary.execution. "mev_protected" builds the tx with the caller-paid Jito tip (jito_tip_lamports, or the platform default) and the approved intent is relayed to the Jito block engine (bundle-only). A failed protected relay is never retried publicly on this rail.

Lane 1 (non-custodial default): builds the unsigned swap transaction server-side, persists it as an intent, and returns {intent_id, approval_url}. NOTHING executes until the user opens the approval URL in their browser and signs with their own wallet. This tool never signs and never sees a key. amount is in input-token base units. The quote includes the technology service fee. After the user approves, poll get_intent_status and report ONLY the persisted on-chain state (CONFIRMED before any success claim).

slippage_bps omitted (None) resolves to the published platform default of 50 bps -- unchanged from before; the returned summary's slippage.applied_source honestly reports "platform_default" in that case rather than falsely claiming "caller".

FEE PARITY: the on-chain technology service fee baked into the unsigned tx is now resolved through the SAME discount-aware pipeline as jupiter_swap -- the tokenized-security classification is resolved ONCE here via the authoritative registry-backed classifier (parity with jupiter_swap's call site) and, together with pay_in_crank, determines the quoted platformFeeBps. Without this an intent proposed via this Lane 1 rail could be fee-classified differently from the identical swap executed via jupiter_swap. Decision: pay_in_crank IS exposed here (not just is_security) -- the fee rate is a quote-time input baked into the unsigned tx before the user ever reaches the approve page, so an agent must be able to request the pay-in-$CRANK discount at proposal time, same as it can on the direct swap path.

GEO GATE: when either leg is a tokenized security this call is geo-gated (Reg S = no US persons) and OFAC-screened, same control jupiter_swap/trade_equity enforce -- jurisdiction declares the caller's jurisdiction once, ip is the caller's origin IP for the Reg-S IP layer.

include_slippage_advisory (default False) adds the venue's own suggested tolerance for this route to summary.slippage (suggested_bps / suggestion / advisory_status) so an approver can compare it with applied_bps before signing. Advisory only: applied_bps, and the unsigned transaction, are unchanged by it. The probe overlaps the transaction build, so it adds little latency.

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": {
      "input_token": "<input_token>",
      "output_token": "<output_token>",
      "amount": "<amount>",
      "wallet_address": "<wallet_address>"
    },
    "name": "create_execution_intent"
  }
}

Input Schema

Name	Required	Description	Default
`ip`	No
`amount`	Yes
`caller_id`	No
`input_token`	Yes
`submit_mode`	No
`jurisdiction`	No
`output_token`	Yes
`pay_in_crank`	No
`slippage_bps`	No
`wallet_address`	Yes
`idempotency_key`	No
`allow_unverified`	No
`jito_tip_lamports`	No
`include_slippage_advisory`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 9, 2026

addedInput schema / properties / jito_tip_lamports

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

addedInput schema / properties / submit_mode

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

Changed1 schema field changedOct 6, 2026
- addedInput schema / properties / include_slippage_advisory
```
Added value: +{
+  "default": false,
+  "type": "boolean"
+}
```
Changed3 schema fields changedSep 19, 2026
- addedInput schema / properties / slippage_bps / anyOf
```
Added value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]
```
- changedInput schema / properties / slippage_bps / default
```
Previous value: -50New value: +null
```
- removedInput schema / properties / slippage_bps / type
```
Removed value: -"integer"
```

Changed3 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
+}

addedInput schema / properties / pay_in_crank

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

First observedJul 27, 2026

TDQS

A4.1/5.0

Behavior5/5

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

The annotations only declare a generic mutation profile (readOnly=false, destructive=true, idempotent=false, openWorld=true). The description goes well beyond that: it explains the approve-then-sign flow, that the tool never sees a key, the two submit_modes and that a failed protected relay is never retried publicly, the Reg-S/OFAC gate, and how slippage defaults are honestly attributed. This is exactly the behavioral context annotations cannot carry.

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

Conciseness3/5

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

The first sentence is sharply front-loaded, but the body sprawls into design-note prose ('Decision: pay_in_crank IS exposed here...', repeated 'unchanged from before'/'unchanged by it') with capitalized in-line headers instead of clean structure. Much of the content earns its place, but the density and rambling make it harder to scan than it needs to be.

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 14-param mutation tool with geo-gating and two execution modes, the description covers the critical decision points: modes, approvals, fees, jurisdiction, and the post-approval polling step the agent must follow, and the output schema covers return shape. Only the idempotency/allow_unverified surface and failure behavior are left unaddressed.

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?

With 0% schema description coverage the description has to carry the whole burden, and it does for the non-obvious params: submit_mode values and semantics, jito_tip_lamports (caller-paid Jito tip vs platform default), slippage_bps default resolution to 50 bps, pay_in_crank's quote-time role, jurisdiction/ip for the Reg-S layer, and include_slippage_advisory as advisory-only. It leaves idempotency_key, allow_unverified, and caller_id unexplained, so it is strong but not fully compensating.

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?

The opening sentence names a specific verb+resource ('Create a propose-only execution intent') and its output ('returns an approval URL'), which is enough to separate it from the direct-execution siblings like jupiter_swap and evm_swap. The distinction is real but is buried under subsequent fee-parity and geo-gate prose rather than stated crisply as a contrast.

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 operating context: 'Lane 1 (non-custodial default)' never signs, nothing executes until the user approves in-browser, then 'poll get_intent_status.' It also states the geo-gate condition (tokenized security ⇒ Reg S/OFAC). It stops short of an explicit when-to-use-this-vs-jupiter_swap rule, which the agent must infer from the fee-parity discussion.

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?