Crank Protocol

create_execution_intent

Destructive

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

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 (follow-up to ): 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.

Input Schema

TableJSON Schema

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

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

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.4/5.0

Behavior5/5

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

Goes far beyond the annotations: states the tool never signs and never sees a key, nothing executes until user approval, slippage_bps omission resolves to the 50 bps platform default with honest applied_source reporting, the fee pipeline is discount-aware via pay_in_crank, and the Reg S/OFAC geo-gate is keyed off jurisdiction/ip. The clarification that the tool persists an intent while execution waits on the user complements destructiveHint=true rather than contradicting it.

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?

Purpose and the safety-critical boundary are front-loaded in the first two sentences, and section breaks help navigation. The fee-parity paragraph is over-explained for an agent, however, containing design-decision rationale ('Decision: pay_in_crank IS exposed here', 'Without this an intent... could be fee-classified differently') and a dangling 'follow-up to :' reference that read as implementation history rather than operational guidance.

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 high-complexity tool (11 params, 0% schema coverage, weak annotation set) it covers the complete user flow: propose, hand the approval URL to the user, poll status, and require CONFIRMED on-chain state before any success claim, plus fee, slippage, and regulatory behavior. Remaining gaps are the non-obvious params (allow_unverified, idempotency_key) and intent/approval-URL expiry, but an agent can invoke and complete the flow correctly from this text.

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 coverage the description carries the full burden, and it delivers real semantics for the trickiest parameters: amount is in input-token base units, slippage_bps None means the 50 bps platform default, pay_in_crank is a quote-time fee input, and jurisdiction/ip drive the geo-gate. However, allow_unverified, caller_id, and idempotency_key remain unexplained, which is a meaningful gap at 0% schema coverage.

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?

Opens with a specific verb+resource: 'Create a propose-only execution intent; returns an approval URL to hand to the user.' The Lane 1 non-custodial framing plus repeated contrast with jupiter_swap and trade_equity clearly differentiates it from swap-execution siblings, and it names the follow-up tool (get_intent_status). An agent can tell what this does and what it isn't without opening 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?

Gives the full when-and-how: this is the non-custodial default that builds an unsigned tx and returns an approval URL for the user to sign, and it instructs the agent to poll get_intent_status afterward and report only persisted on-chain state. It does not, however, provide an explicit 'use X instead when...' exclusion for the direct/custodial swap path; alternatives are named only in the context of fee parity and gating.

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?