Crank Protocol

get_quotes

Read-onlyIdempotent

Read-only Jupiter quote for a token pair (no execution).

amount is in base units of input_token. Returns routes, price impact, fees, and estimated output. venue_hint is ADVISORY, never required -- see jupiter_swap.

Pass wallet_address (optional) to preview the DISCOUNTED technology service fee that wallet will actually pay -- its volume tier plus $CRANK staker / pay_in_crank / Crank Score discounts. Omit it for the base rate. This stays a free read either way.

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

Input Schema

TableJSON Schema

Name	Required	Description	Default
`amount`	Yes
`caller_id`	No
`venue_hint`	No
`input_token`	Yes
`output_token`	Yes
`pay_in_crank`	No
`slippage_bps`	No
`wallet_address`	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"
```
Changed2 schema fields changedAug 5, 2026
- addedInput schema / properties / pay_in_crank
```
Added value: +{
+  "default": false,
+  "type": "boolean"
+}
```
- addedInput schema / properties / wallet_address
```
Added value: +{
+  "default": "",
+  "type": "string"
+}
```
First observedJul 27, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, it discloses concrete behavior: no execution, free read, returned fields (routes, price impact, fees, estimated output), default slippage of 50 bps, and that slippage.applied_source reports platform_default rather than caller. It also explains wallet_address-dependent fee discount logic.

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 longer than average but front-loaded with the core purpose and contains useful detail rather than filler. Minor redundancy such as "unchanged from before" and "stays a free read" could be trimmed, but the structure is logical and each section adds value.

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 an 8-parameter tool with no schema descriptions, it covers the required parameters, key default behavior, optional quoting paths, and fee-preview semantics. The output schema and annotations fill in result and safety details, leaving only occasional gaps such as caller_id semantics.

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 compensates well: amount is in base units of input_token, venue_hint is advisory, wallet_address previews discounted fees, and slippage_bps has a documented default. The only parameter left unexplained is caller_id, though input_token and output_token are implicit from the token pair framing.

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 action and scope: "Read-only Jupiter quote for a token pair (no execution)." It clearly distinguishes get_quotes from its execution sibling jupiter_swap by explicitly disclaiming execution.

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 says this tool does not execute and points to jupiter_swap as the execution destination. It also gives clear conditional usage: pass wallet_address to preview discounted fees, omit it for the base rate, and treat venue_hint as advisory and never required.

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?