Returns address map by chain type (EVM, SOL, etc.). Call before transfer/swap tools to get the sender address.
| Name | Required | Description | Default |
|---|---|---|---|
| mcp_token | No | MCP session token obtained from login (dex_auth_google_login_poll or dex_auth_gate_login_poll). MUST be provided in every call to this tool after login; omitting it will result in 403 | |
| account_id | Yes | Account ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description presents a pure read operation ('Returns address map'), but the annotations declare readOnlyHint=false and destructiveHint=true. This is a direct contradiction—there is no mention of any destructive side effects, and the tool's name and description imply a non-mutating query. Score is 1 due to contradiction.
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?
The description is two short sentences, front-loads the purpose, then adds usage context. No wasted words.
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?
The tool has no output schema, and while the description gives a high-level return type ('address map by chain type'), it lacks detail on the exact format and is contradicted by the annotations, leaving ambiguity about side effects. Thus a 3.
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?
Both parameters (mcp_token, account_id) are fully described in the schema (100% coverage). The description adds no additional parameter meaning, so it stays at the baseline 3.
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 clearly states the tool returns an address map keyed by chain type (EVM, SOL, etc.) and explicitly positions it as a prerequisite for transfer/swap operations. This distinguishes it from sibling wallet tools like get_token_list or get_total_asset.
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 gives an explicit instruction to call before transfer/swap tools to obtain the sender address. However, it does not mention any alternatives or when not to use, so it stops short of a full 5.
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.
Most tools have clear, distinct roles (auth flows, market data, swap stages, wallet operations). A few ambiguities exist, such as dex_tx_get_sol_unsigned vs dex_tx_transfer_preview and dex_agentic_report's name not matching its description, but overall agents can reliably select the correct tool.
Naming is inconsistent: while all tools share the dex_ prefix and category segments, some use get_*, others list_*, and several are noun phrases (dex_chain_config, dex_tx_gas, dex_tx_detail). Auth tool ordering also varies (gate_login_start vs login_gate_wallet), making the pattern less predictable.
With 47 tools, the server is over-scoped and burdensome for agents to navigate. Even though the broad DEX domain justifies many features, this exceeds the 25+ threshold for 'too many' and could benefit from consolidation into fewer, higher-level tools.
The tool set comprehensively covers DEX workflows: auth, market data, token info, wallet balances, transfer/swap pipeline, cross-chain bridge, and x402 payments. Minor gaps include lack of explicit swap cancellation or withdrawal execution, but these are secondary to the core functionality.