Skip to main content
Glama

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".

include_slippage_advisory (default False) adds the venue's own suggested tolerance for this route to the slippage block (suggested_bps / suggestion / advisory_status). Opt-in because it costs one extra venue round trip (~400 ms measured); requires wallet_address. Advisory only -- applied_bps is always exactly what executes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
amountYes
caller_idNo
venue_hintNo
input_tokenYes
output_tokenYes
pay_in_crankNo
slippage_bpsNo
wallet_addressNo
include_slippage_advisoryNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / include_slippage_advisory
      Added value: +{
      +  "default": false,
      +  "type": "boolean"
      +}
  2. Changed3 schema fields changed
    • 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"
  3. Changed2 schema fields changed
    • addedInput schema / properties / pay_in_crank
      Added value: +{
      +  "default": false,
      +  "type": "boolean"
      +}
    • addedInput schema / properties / wallet_address
      Added value: +{
      +  "default": "",
      +  "type": "string"
      +}
  4. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare read-only/idempotent/non-destructive, and the description adds substantial beyond-schema behavior: the None slippage default resolves to 50 bps with applied_source honestly reporting 'platform_default', the advisory flag costs a ~400 ms venue round trip and requires wallet_address, and applied_bps is always what actually executes. These are exactly the operational details an agent cannot get from 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?

Front-loaded with purpose and safety, then parameter behavior in descending importance. It is longer than typical, with some conversational emphasis (bold-style caps, 'honestly reports'), but nearly every sentence conveys a distinct constraint rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter read tool with an output schema, the description covers the decision-relevant unknowns: defaulting behavior, the discount path, the opt-in cost, and what executes versus what is advisory. Return structure is left to the output schema, which is appropriate.

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 carries the full burden and mostly succeeds: amount is in input_token base units, venue_hint is advisory-only, wallet_address is optional and only affects fee preview, slippage_bps None maps to a 50 bps default, include_slippage_advisory defaults False with a documented cost and dependency. caller_id and pay_in_crank are only obliquely addressed (the latter via the discount list), leaving minor gaps.

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+scope: 'Read-only Jupiter quote for a token pair (no execution).' It immediately distinguishes itself from the execution sibling by naming jupiter_swap, so an agent can route without opening either 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 clear conditional guidance: omit wallet_address for base rate, pass it to preview discounts, opt into include_slippage_advisory only when the extra venue round trip is worth it, and venue_hint is advisory with a pointer to jupiter_swap. It never explicitly contrasts against other quote siblings like evm_swap_quote or get_bridge_quote, so routing between them is left to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources