Skip to main content
Glama

Bridge costs between networks

get_bridge_quotes
Read-onlyIdempotent

Cheapest live route and total cost to move about $100 of USDT/USDC/ETH/BTC between networks (e.g. Tron to BNB Chain, Ethereum to Base, BTC to Ethereum), with time and bridge used. Filter by source and destination network.

Input Schema

NameRequiredDescriptionDefault
toNo
fromNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, open-world, non-destructive semantics, so the bar is lower. The description adds meaningful context beyond them: quotes are for a ~$100 transfer size, supported assets are USDT/USDC/ETH/BTC, and the response includes the bridge used and time estimate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence with the essential scope (cheapest route, total cost, fixed amount, assets, output fields) front-loaded before the filter note. No filler.

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 two-param read-only tool with no output schema, the description covers what is returned (cost, time, bridge) and the fixed transfer size, which an agent needs to interpret the result. Only minor gaps remain, such as multi-asset aggregation behavior.

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 0%, but both parameters are enums with fully self-describing network values. The description only says 'filter by source and destination network', which maps to from/to but adds no syntax or edge-case guidance (e.g. whether from can equal to, or per-asset behavior). Baseline for enum-only params.

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?

States a specific verb+resource: it returns the cheapest live bridge route and total cost for moving ~$100 of a named set of assets between networks, with examples (Tron→BNB Chain, Ethereum→Base). This clearly separates it from siblings like get_network_fees or get_exchange_withdrawal_fees.

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?

The closing sentence 'Filter by source and destination network' implies how to use the tool, but there is no explicit guidance on when to prefer it over get_network_fees or get_exchange_withdrawal_fees, and no exclusions or prerequisites. Usage is inferable but not spelled out.

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