CryptoPulse Data API

bridge_quote

[$0.01 USDC per call via x402] Best cross-chain bridge route and quote for moving a token between chains (Base, Ethereum, Arbitrum, Optimism, Polygon, BSC, Avalanche, Solana and more): output amount, fees, gas, duration, via Relay (LI.FI fallback).

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": {
      "to_chain": "<to_chain>",
      "amount": "<amount>"
    },
    "name": "bridge_quote"
  }
}

Input Schema

Name	Required	Description
`amount`	Yes	Amount in human units, e.g. 100
`slippage`	No	Max slippage fraction, 0.0005-0.05 (default 0.005)
`to_chain`	Yes	Destination chain name or id
`to_token`	No	Token symbol or address on the destination chain (default USDC)
`from_chain`	No	Source chain name or id (base, ethereum, arbitrum, optimism, polygon, bsc, avalanche, solana, ...)
`from_token`	No	Token symbol or address on the source chain (default USDC)
`to_address`	No	Optional recipient wallet on the destination chain (Solana address for Solana destinations)
`from_address`	No	Optional sender wallet; required for an executable transaction request

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 5, 2026

addedInput schema / properties / to_address

Added value: +{
+  "description": "Optional recipient wallet on the destination chain (Solana address for Solana destinations)",
+  "type": "string"
+}

AddedNov 5, 2026

TDQS

A3.7/5.0

Behavior4/5

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

With no annotations, the description carries the burden well: it discloses the paid-call requirement ($0.01 USDC via x402) and the provider routing with LI.FI as fallback, both of which are non-obvious behaviors. It stops short of stating whether the tool only quotes versus also submits a transaction, which matters for a routing tool.

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?

One dense sentence with the cost and payment mechanism front-loaded in brackets, then purpose, chains, outputs, and provider. Efficient, though the parenthetical chain list is longer than needed given the schema already enumerates examples.

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 output schema and no annotations, the description usefully previews the return fields (output amount, fees, gas, duration) and the payment cost. The main remaining gap is execution semantics—whether passing from_address turns this into a transaction request.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameter meaning is already fully documented, including defaults (USDC), slippage range, and the from_address execution note. The description adds nothing parameter-specific beyond the output fields it promises, so baseline 3 applies.

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?

States a specific verb and resource ('Best cross-chain bridge route and quote for moving a token between chains'), enumerates supported chains, and names the routing provider with a fallback. It reads clearly as a cross-chain quote distinct from a same-chain swap, though it never explicitly contrasts itself with the swap_quote sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Use is implied by the word 'quote' and the cross-chain framing, but there is no explicit when-to-use or when-to-prefer-swap_quote guidance, and no stated prerequisites beyond the cost line.

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

All CryptoPulse Data API 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?