Crank Protocol

trade_equity

Destructive

Spot-trade a tokenized equity (xStocks / Ondo) via Jupiter, non-custodial.

side: buy | sell. amount is in base units of the INPUT token (USDC 6dp for a buy, the equity token for a sell). These are tokenized SECURITIES: the call is geo-gated (Reg S = no US persons; declare jurisdiction once via the jurisdiction arg) and OFAC-screened, and requires per-execution confirmation -- WITHOUT confirm=true it returns a quote + disclaimer and does NOT execute (no autonomous equity execution). With confirm=true it returns an UNSIGNED base64 tx to sign + broadcast; pass signed_transaction to broadcast a caller-signed tx. Value-bearing: past the daily free tier an x402 payment_header is required. ip = caller origin IP for the Reg S geo gate (US IP -> refused even with an attestation; an agent's Railway Singapore egress resolves to SG and passes). venue_hint is ADVISORY, never required -- equity routes via the issuer registry (one surface today); an unknown hint raises.

idempotency_key (optional): see jupiter_swap -- same replay-on-retry semantics, same key reused across build + broadcast.

verify (extending default True): when broadcasting (signed_transaction supplied), await on-chain confirmation and re-read the equity mint balance -- the response gains a verification block ({confirmed, slot, post_state, expected_vs_actual}). Gate follow-on decisions on verification.confirmed, never on tx_signature alone. Set False to skip for latency-sensitive callers. Verify any prior signature later with the standalone verify_transaction tool.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`ip`	No
`side`	Yes
`amount`	Yes
`symbol`	Yes
`verify`	No
`confirm`	No
`caller_id`	No
`venue_hint`	No
`jurisdiction`	No
`pay_in_crank`	No
`slippage_bps`	No
`payment_header`	No
`wallet_address`	Yes
`idempotency_key`	No
`allow_unverified`	No
`signed_transaction`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already mark this as destructive and non-idempotent, but the description goes far beyond: it discloses the two-phase execution (quote vs. execute), the confirm flag requirement, the unsigned transaction flow, the geo-gate on IP, the OFAC screening, the daily free tier and x402 payment_header, and the verification block behavior. All of this adds critical context that the agent needs to call the tool correctly and safely, without any contradiction to the annotations.

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?

The description is long but tightly packed with essential operational details. It starts with the core purpose, then systematically covers side/amount units, geo/confirmation requirements, the verification flow, idempotency, and the venue hint. Every sentence contributes meaning; there is no filler. While it could be slightly more streamlined, the density is justified by the tool's complexity.

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?

This is a complex 16-parameter tool with an output schema. The description covers the execution pipeline thoroughly: the confirm gating, the unsigned tx flow, the verification block and its use, the geo/IP constraints, and payment requirements. It also references jupiter_swap for idempotency semantics and verify_transaction for later verification. Some parameters like slippage_bps and pay_in_crank are left unexplained, but they have sensible defaults and are not central to the core workflow. For a tool of this complexity, the description is remarkably complete.

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?

The input schema has 0% description coverage, so the description carries the entire burden. It explains the meaning of side (buy/sell), amount units (base units of input token), confirm, verify, jurisdiction, ip, venue_hint, idempotency_key, payment_header, and signed_transaction. It does not explain all 16 parameters (e.g., slippage_bps, pay_in_crank, allow_unverified, caller_id), but it covers the critical ones with sufficient detail. Given the schema is bare, this is a substantial compensation, so a 4 is appropriate rather than 5.

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 description opens with a precise statement: 'Spot-trade a tokenized equity (xStocks / Ondo) via Jupiter, non-custodial.' It identifies the specific asset class, venue, and execution model, clearly distinguishing it from general-purpose swap tools like jupiter_swap or lst_swap. The wording is unambiguous about the resource and action.

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?

The description explicitly states when to use this tool (for tokenized equities) and when not to (e.g., general swaps go to jupiter_swap). It also names an explicit alternative for verification: 'Verify any prior signature later with the standalone verify_transaction tool.' The geo-gating and jurisdiction requirements further clarify the usage constraints. This is a strong guidance that routes the agent correctly.

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

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.2/5.0

Disambiguation2/5

Multiple tools overlap significantly: close_perp_position vs perp_close, get_leaderboard vs get_score_leaderboard vs get_strategy_leaderboard, get_venue_status vs get_all_venues_status, send_token_social vs bulk_send_social, and get_crank_score vs get_score. Several read-only tools have nearly identical purposes, and the descriptions do not always clarify boundaries.

Naming Consistency4/5

Most tools follow a consistent verb_noun snake_case pattern (get_balances, create_strategy, set_alert, list_webhooks). However, there are deviations like 'lst_swap', 'jupiter_swap', 'flash_loan', 'sr_backtest', and the use of both 'get_' and 'list_' for reads, plus category prefixes like 'perp_' and 'strategy_' that vary in order. Overall still readable and predictable.

Tool Count1/5

177 tools is an extreme count for any server, far exceeding the 25+ threshold for 'too many'. Even a full DeFi platform does not need this many separate operations; the surface is overwhelming and clearly not well-scoped.

Completeness3/5

The domain (Solana DeFi trading) is covered extensively across swaps, perps, lending, staking, strategies, signals, and support. However, there are notable gaps: no lend_withdraw, no direct way to close a lending position, no spot order cancellation (though aggregator-based swaps may not need it), and a general lack of tiered account management. The huge number of tools makes it hard to identify missing lifecycle steps.

Resources

Need Help?