get_token_infoGet a token's on-chain metadata (display name, decimals, EIP-712 version) for a given chain. Needed when building an EIP-3009 deposit signature's tokenName/tokenVersion fields. Rate limited to 6 calls/minute per caller, no more than one call every 10s.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | Chain name, e.g. BASE, ETHEREUM, POLYGON. | |
| token | Yes | Token symbol, e.g. USDC, USDT, MUSD, RLUSD, USDG, USDE, PYUSD. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag this as a read-only, non-destructive call; the description adds rate limiting (6 calls/min, 10s spacing) and the precise data fields returned. This is useful behavioral context beyond annotations, though it omits error handling and any authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff: purpose comes first, followed by use-case and rate limit. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter read-only lookup with full schema coverage, the description provides the target metadata fields, the exact use-case, and call constraints. Nothing essential for selecting or invoking the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both token and chain parameters described and exemplified, so the description does not need to repeat them. The description adds context about how the returned values feed into tokenName/tokenVersion fields, but it provides no parameter-format details beyond what the schema already gives.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and direct object: 'Get a token's on-chain metadata (display name, decimals, EIP-712 version) for a given chain.' This names the exact data returned and the chain dimension, clearly separating it from balance, status, and config sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Needed when building an EIP-3009 deposit signature's tokenName/tokenVersion fields,' giving a concrete trigger for use. It does not name alternative tools or state when not to use it, so it falls just short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Every tool targets a distinct operation: auth challenge/verify, config read/build/submit, deposit/withdrawal prepare/submit/status, balances, rewards, pools, and small utility lookups. Descriptions explicitly cross-reference one another (e.g., get_balances vs get_bridge_balances vs get_rewards), making accidental misselection very unlikely.
Tool names follow a consistent snake_case verb_noun pattern: get_* for reads, prepare_* for signing-payload construction, submit_* for signed writes, and list_pools for the catalog. The verb families map cleanly onto the tool's lifecycle stages, so the naming is predictable and scannable.
19 tools is on the higher end, but the count is justified by the domain: authentication, config lifecycle, deposit/withdrawal prepare-and-submit flows, status polling, balances, and reward reading each need dedicated surface area. A few utilities (get_token_info, get_transaction_costs, get_withdrawal_version) feel slightly granular, but none are redundant.
The tool set covers the core lifecycle well: auth, config creation/update, deposit, withdrawal, status tracking, balance/reward queries, and pool discovery. Minor gaps exist (no reward claim endpoint, no deposit/withdrawal history listing, no explicit rebalancer deletion), but the descriptions provide workarounds and clearly scope what is intentionally unsupported.