Gate DEX MCP

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the agent knows this is a mutating and potentially destructive operation. The description adds minimal behavioral context by specifying the action is 'with the wallet service', but it does not clarify side effects, whether registration overwrites existing data, or what happens on success. It does not contradict the annotations.

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 a single sentence of eight words, front-loaded with the key verb and resource. There is zero redundancy or filler, making it highly concise and easy to parse.

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?

Despite having a rich schema and annotations, the description leaves significant gaps: it doesn't explain what 'agentic wallet addresses' are, when this tool should be used (e.g., during onboarding), or what the effect of 'registering' is given the destructiveHint. With no output schema and a complex nested parameter structure, the description alone is insufficient for an agent to fully understand the tool's purpose and side effects.

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 description coverage is 100% for both parameters (wallets and mcp_token), so the schema already documents their meanings and requirements. The description adds no additional parameter-level semantics, so the baseline score of 3 applies.

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 uses a specific verb ('Register') and a specific resource ('agentic wallet addresses with the wallet service'), which clearly states the tool's function. However, it does not explicitly distinguish itself from sibling wallet-binding tools like dex_wallet_bind_exchange_uid or dex_wallet_replace_binding, and the term 'agentic wallet addresses' is somewhat ambiguous without additional context.

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?

The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites such as needing to log in first or requiring a token. While the schema field description for mcp_token mentions the login requirement, the tool description itself offers no contextual usage hints.

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

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

Discloses the [write] side effect, conditional mcp_token replacement, and rebind behavior, complementing the destructiveHint=true annotation with specific details.

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, front-loaded with the main purpose and packed with relevant behavioral details without waste.

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?

Covers return statuses, side effects, and key conditions. With schema and annotations providing parameter and safety details, the description is complete for the tool's moderate complexity.

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% and describes both parameters fully. The description only restates auto_replace_binding behavior without adding new meaning.

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?

States it polls Gate OAuth and returns pending/ok/error, clearly distinguishing from start or Google poll siblings. The verb 'Poll' is specific and the resource 'Gate OAuth' is explicit.

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?

Flow_id tied to dex_auth_gate_login_start implies sequential use, and auto_replace_binding guidance is provided. However, it doesn't explicitly state when not to use this tool vs alternatives.

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

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

The description adds useful behavior details: it returns a verification_url and explains the bind-only mode without replacing mcp_token. However, it does not explain the destructive nature (annotations indicate destructiveHint=true) or any other side effects, leaving the agent to infer the implications of starting a new OAuth flow.

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 compact and front-loaded: two sentences, each conveying a distinct and necessary piece of information (the start action and the bind mode). No filler or redundant phrasing.

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?

While the tool's direct action and return are clear, the description omits the broader OAuth flow—specifically that after starting, the agent should use the sibling poll tool to check completion. This is essential for correct multi-step usage. The annotations and schema cover safety and parameters, but the flow context 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% and already describes 'link_mcp_token' thoroughly. The description only restates a condensed version of the schema's meaning, adding no new semantic information. Thus it meets the baseline but does not exceed it.

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 action: 'Start Gate device OAuth' and immediately mentions the return value 'verification_url'. It distinguishes this from sibling tools like 'dex_auth_gate_login_poll' (polling) and 'dex_auth_google_login_start' (Google OAuth) by naming the specific protocol and operation.

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?

The description provides context for when to use the 'link_mcp_token' parameter (on a Google session to bind without replacing mcp_token), which is a clear usage guideline. However, it does not explicitly contrast this tool with alternatives like Google login start or mention the follow-up polling flow, so it lacks full exclusionary guidance.

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

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

The description goes beyond annotations by disclosing a critical side effect: on success, it immediately replaces the stored mcp_token with a token tied to a different account. This is exactly the kind of behavioral context beyond the structured annotations that helps an agent understand the impact of invoking the tool.

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 concise sentences, front-loads the primary action and return values, and includes the essential side-effect warning without any filler. Every phrase adds meaningful information.

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 single-parameter polling tool with no output schema, the description covers purpose, return states, and the significant token replacement side effect. This is sufficient context for an agent to understand and safely invoke the tool.

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?

The input schema already provides 100% coverage for flow_id, stating it is returned by dex_auth_google_login_start. The description does not add further parameter semantics, so the baseline of 3 is appropriate.

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 uses a specific verb ('Poll') and resource ('Google OAuth flow'), states the return statuses (pending/ok/error), and clearly differentiates this polling tool from the sibling start tool and gate poll alternatives by its focus on Google OAuth and token replacement.

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 clearly implies usage: call after dex_auth_google_login_start, as indicated by the flow_id description referencing the start tool. It provides context about the polling flow, though it does not explicitly state when not to use this tool or mention alternatives like the gate login poll.

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

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

The description only says 'returns' a URL, giving no indication of side effects. The annotations include destructiveHint=true and idempotentHint=false, but the description does not disclose any state-changing behavior, such as invalidating existing sessions or starting an auth session. This is a significant transparency gap given the destructive hint.

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 a single, focused sentence that earns its place. It is not overly verbose. However, it is quite sparse, missing contextual details that would make it fully effective, so it doesn't earn a 5.

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 is part of a multi-step OAuth flow (start, poll), but the description does not mention the next step or that the returned URL is meant for a user to visit. There is no output schema, so the description should explain the return value and flow, but it only gives a minimal phrase. The destructive and open-world hints also go unaddressed, making the description inadequate for an agent to fully use the tool correctly.

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?

The tool has zero parameters, so the description does not need to explain parameter semantics. Baseline for 0 params is 4; no additional information is required or expected.

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 a browser verification URL for Google device OAuth, with a specific verb and resource. It distinctly differentiates this from sibling tools like dex_auth_google_login_poll, which is the polling step.

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?

The description implies this is the start of the Google device OAuth flow, but it does not explicitly state when to use it, what to do after receiving the URL, or mention the polling alternative. The context is inferred from the tool name and sibling tools, not from clear guidance.

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

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

Annotations already mark this as destructive and non-read-only, and the description adds significant context by stating that on success the stored mcp_token is immediately replaced and tied to a different account. This goes beyond the annotation flags by naming the specific state change and account-switching implication. It does not contradict the annotations.

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 very short—two sentences—and front-loads the core purpose in the first clause. The warning about token replacement is valuable and concise. It is slightly redundant with the '[write]' tag and the annotation, but overall it is efficient and easy to scan.

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 simple 2-parameter tool with good schema coverage and annotations, the description covers purpose and key destructive behavior. However, there is no output schema and the description does not describe the return value (e.g., whether the MCP token is returned) or any error/failure conditions. It also assumes the agent knows the OAuth flow context, so it is not fully complete.

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 parameters ('code' and 'redirect_url') having clear descriptions. The description does not add any additional parameter-level meaning beyond what the schema already provides, which aligns with the baseline of 3 when schema handles parameter documentation.

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 states a clear purpose: exchanging a Gate OAuth code for an MCP token. It names the specific resource (Gate OAuth code) and the outcome (MCP token), which distinguishes it from sibling Google login and start/poll flow tools. However, the phrasing is slightly telegraphic and does not explicitly mention 'login' or 'authentication', so it loses a point for full clarity.

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?

The description implies usage: this tool is for the final step of Gate OAuth login, exchanging an authorization code for a token. It also warns about replacing the stored token, which is important post-success guidance. However, it does not explicitly state when to use this tool versus the sibling start/poll tools or Google alternatives, so it lacks explicit exclusions.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds valuable context by warning that on success it 'immediately replace[s] any stored mcp_token' and that the 'new token is tied to a different account.' This goes beyond the structured annotations to disclose a specific side effect and account-switching behavior, earning a 4.

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 sentences long, front-loads the main purpose, and every sentence adds meaningful information. There is no fluff or redundancy. It is an example of concise, well-structured documentation.

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 auth tool with no output schema, the description covers the core purpose and side effect, but it lacks critical flow context: it does not explain that the code must come from a prior login-start step, nor does it describe what the tool returns on success. Given the large sibling family, an agent might not understand the full lifecycle, so completeness is only adequate.

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 description coverage is 100% for both parameters (code and redirect_url), so the schema already explains their meaning. The description only mentions 'Google OAuth code' and does not add new semantics for redirect_url. With full schema coverage, the baseline of 3 is appropriate.

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 a specific action: 'Exchange Google OAuth code for MCP token.' This identifies the verb (exchange), the input (Google OAuth code), and the output (MCP token), and it distinguishes this tool from siblings like dex_auth_google_login_start and dex_auth_google_login_poll, which handle initiation and polling rather than token exchange.

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?

The description implies usage when a Google OAuth code is available, but it does not explicitly state when to use this tool versus alternative auth tools, nor does it mention prerequisites like having first called dex_auth_google_login_start. The guidance is implicit rather than explicit, so it falls short of a 4.

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

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

Annotations already flag destructiveHint=true and openWorldHint=true. The description adds specificity by naming exactly what is destroyed—the MCP session associated with the token—which goes beyond the generic annotation. It doesn't detail post-revocation consequences, but the core effect is disclosed.

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?

One short, front-loaded sentence with no redundant words. It states the action and the target parameter efficiently, ideal for a single-parameter logout tool.

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?

Given the simple one-parameter schema, the annotations, and the straightforward action, the description is sufficiently complete for an agent to invoke the tool correctly. It doesn't mention return value or post-conditions, but that is not essential for this straightforward revocation operation.

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?

The input schema provides 100% coverage for the single required parameter, and the description does not add new semantics beyond identifying the token as the session identifier. Baseline 3 is appropriate since the schema handles the parameter meaning.

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 action ('Revoke') and the resource ('the MCP session identified by mcp_token'). It is specific and distinct from sibling tools, which are mostly login/poll/wallet operations.

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?

The description makes clear this is the session-revocation/logout counterpart to the auth login siblings. It does not explicitly mention when not to use it, but the context is unambiguous enough for selection among related auth tools.

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

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

The description only states that it 'returns' config, adding no behavioral detail about side effects, permissions, rate limits, or the meaning of the annotations. The annotations include destructiveHint: true, which is not addressed by the description, leaving ambiguity about whether this tool has destructive side effects. Without clarification, the description does not help the agent understand the true safety profile beyond what annotations already provide.

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 concise: two sentences with the primary purpose in the first sentence and usage guidance in the second. It is front-loaded and contains no filler or redundant content, effectively conveying essential information in minimal length.

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 simple config-retrieval tool with only two parameters and no output schema, the description is adequate. It explains what is returned and how to use it. However, it does not address the destructiveHint annotation or elaborate on potential side effects, nor does it describe the return format in detail (though an output schema is absent). This leaves some contextual gaps but is not severely incomplete.

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%, so the input schema fully describes both parameters (chain and mcp_token) including case-insensitivity and the 403 error for missing token. The description adds minimal parameter-level information, only implying that the returned chain value is the output from the chain parameter. Since schema already does the heavy lifting, the description's contribution is marginal.

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's function: 'Returns chain config (networkKey, accountKey, chainID).' It specifies the exact resource (chain config) and the exact verb (returns), and it goes beyond by explaining the purpose of the returned value in subsequent transfer/sign/broadcast tools. This distinguishes it from other sibling tools that perform different operations.

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?

The description explicitly says 'Use the returned chain value in all subsequent transfer/sign/broadcast tools,' which provides clear guidance on when this tool should be used (before transfer/sign/broadcast operations). However, it does not mention any alternatives or scenarios where this tool should not be used, so it lacks exclusions.

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

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

Annotations declare destructiveHint=true and readOnlyHint=false, but the description presents a pure data retrieval operation with no mention of side effects or destructive behavior. This is a direct contradiction and the description does not clarify the annotation, leaving the agent with conflicting signals.

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 extremely concise, front-loading the core purpose in a short clause and adding two cross-references. There is no fluff. However, it omits critical behavioral context, making it slightly too sparse for a balanced tool description.

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?

With no output schema, the description should explain return values and behavior, but it does not describe the candle response format, pagination, or any side effects. Given the misleading destructiveHint annotation, the description needs to clarify whether this operation has any state-changing behavior. The tool is relatively simple, but these gaps make it incomplete.

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 description coverage is 100%, so the schema already documents all parameters. The description adds only a high-level grouping ('period and window') that does not enhance understanding of individual parameters. It meets the baseline but no more.

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 OHLCV candles and specifies the filtering dimensions (period and window). It also distinguishes from siblings by pointing to get_tx_stats for volume aggregates and get_pair_liquidity for pool events, making the tool's unique role unambiguous.

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?

The description gives explicit alternative guidance: 'Volume aggregates→get_tx_stats. Pool events→get_pair_liquidity.' This tells the agent when to use other tools instead, which is strong usage differentiation. The primary use case is inherent in 'OHLCV candles'.

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

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

Annotations declare readOnlyHint=false and destructiveHint=true, while the description implies a read-only data query ('events'). This is a direct contradiction, as events are typically informational and non-destructive. The description provides no clarification about side effects, permissions, or other behavioral traits, so it fails to align with annotations.

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 concise, consisting of one sentence plus two arrows. It front-loads the core purpose and efficiently references alternatives. However, the arrows are cryptic and could be clearer, so it slightly loses points for structure.

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?

With no output schema and minimal description, the tool's return structure is unspecified. The description doesn't explain what 'events' includes, how pagination works, or the interplay between required token_address and optional pair_address. The alternative references are helpful but do not compensate for the missing operational context.

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 description coverage is 100%, so the schema already documents all five parameters. The description adds no parameter-specific meaning (e.g., how pair_address relates to token_address or pagination behavior). Baseline for full coverage is 3; the description does not compensate beyond that.

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 states 'AMM pool deposit and withdrawal events,' which indicates the tool returns liquidity-related events, but it lacks an explicit verb like 'retrieve' or 'list.' The name suggests pair liquidity, creating ambiguity about whether it returns current liquidity or event history. It distinguishes from get_kline and get_tx_stats but not from other market 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?

The description explicitly maps alternative tools for different needs: 'Candlesticks→get_kline' and 'Volume stats→get_tx_stats.' This tells when NOT to use this tool, implying it should be used for AMM pool deposit/withdrawal events. However, it doesn't provide explicit scenarios beyond those alternatives.

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

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

The annotations declare destructiveHint=true and readOnlyHint=false, while the description clearly describes a read-only market data retrieval function ('buy/sell volume and tx counts'). This is a direct contradiction, as the description implies a non-destructive operation. The description also provides no additional behavioral context to resolve this.

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 sentences and entirely functional. The first sentence states the tool's core function, the second immediately provides routing to sibling tools. No wasted words, and structure is front-loaded.

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 simple data retrieval tool with three parameters, the description covers purpose and alternatives, but it omits return value details (no output schema exists) and does not address the destructive annotation contradiction. The interval ranges (5m–24h) add some context, but overall the description leaves some gaps for agent decision-making.

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 description coverage is 100%, so all three parameters are already explained in the schema. The description adds no parameter-level detail beyond the schema, matching the baseline of 3 where the schema does the heavy lifting.

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 states the tool provides 'Per-interval buy/sell volume and tx counts (5m–24h)', which is a specific, searchable function. It also distinguishes itself from related tools by explicitly directing to get_kline for candlesticks and get_pair_liquidity for pool events, making its purpose unambiguous.

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?

The description clearly tells when to use this tool (for volume and tx stats) and names alternatives for other data types ('Candlesticks→get_kline. Pool events→get_pair_liquidity.'). It lacks an explicit 'do not use when...' list, but the alternative mapping serves as strong guidance.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds no additional behavioral context such as potential side effects, chain support, or rate limits. It neither contradicts nor enriches the annotation profile.

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 a single, front-loaded sentence with no filler. It is appropriately sized for the minimal information it conveys.

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 description is minimal for a generic RPC proxy. While the schema details parameters and annotations cover safety, the description does not explain the response format (no output schema), supported chains/methods, or when to use it. It is adequate for basic selection but leaves gaps.

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 description coverage is 100%, so the baseline is 3. The description does not add any parameter-specific meaning beyond what the schema already provides with examples like eth_blockNumber and getLatestBlockhash.

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's action ('Proxy a JSON-RPC call to a blockchain node'), with a specific verb and resource. However, it does not distinguish itself from sibling tools like dex_tx_send_raw_transaction or other RPC-related operations, so it falls short of a top score.

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?

The description provides no guidance on when to use this tool versus alternatives. There is no mention of use cases, exclusions, or related tools. The mcp_token requirement in the schema is authentication-related, not usage guidance.

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

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

Annotations indicate destructiveHint=true and readOnlyHint=false, but the description presents the tool as a pure information retrieval operation. It does not disclose any potential side effects, auth requirements, or why the destructive hint is set. The description adds no behavioral context beyond the annotations.

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 very short and front-loaded with key data categories, but the telegraphic style and 'Security audit→get_risk_info' arrow are slightly cryptic. It is concise but at the expense of clarity.

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?

With no output schema and annotations indicating destructive potential, the description should clarify the return structure and side effects. It only lists data categories and an alternative tool, leaving the agent to guess about response format and behavioral edge cases.

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%, so the baseline is 3. The description only mentions 'optional top holders', which adds no new information over the existing schema description. It provides no extra guidance on chain or address format.

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 lists concrete return contents (price, market snapshot, metadata, optional top holders) and is backed by the tool name 'get_coin_info'. It also distinguishes itself from the risk tool by pointing to dex_token_get_risk_info for security audits, though it lacks an explicit verb.

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?

The description gives one explicit alternative ('Security audit→get_risk_info'), which clarifies when not to use this tool. However, it does not compare to other market/token siblings like dex_market_get_pair_liquidity or dex_token_ranking, so usage guidance is only partially complete.

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

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

Annotations indicate destructiveHint: true, but the description does not disclose any destructive behavior, nor does it address openWorldHint or idempotentHint false. This leaves a significant transparency gap, as agents may assume a safe read operation based on the 'get' framing.

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 a single concise sentence, front-loaded with the main action and no fluff. It efficiently conveys the core functionality.

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 description omits return format, pagination, and any explanation for the destructiveHint annotation. Given the tool's query nature and the surprising annotations, more context on side effects or data scope would be necessary for complete understanding.

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?

The schema covers all 4 parameters with descriptions, so baseline is 3. The description adds 'chain optional for all networks,' which duplicates the schema's info and provides no new semantic value.

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 retrieves tokens launched within a time window, with optional chain filtering. This is specific and distinguishes it from other token-related tools like dex_token_list_swap_tokens or dex_token_ranking.

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?

The description implies usage for finding tokens by creation time but offers no explicit guidance on when to prefer this over other token listing tools. No alternatives are mentioned, so usage context is only implied rather than explicit.

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

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

The description describes a read-only audit operation, but the annotations declare readOnlyHint: false and destructiveHint: true. This is a direct contradiction. Additionally, the description adds no behavioral context about side effects, permissions, or output characteristics, so transparency fails completely.

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 a single sentence with a concise alternative reference. It front-loads the core purpose and wastes no words, achieving high information density in minimal space.

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 description gives enough to understand the tool's scope but lacks output details and does not reconcile the annotation conflict. Since no output schema exists, the description should clarify what a typical response contains; the mention of honeypot, tax, and ownership flags partially helps, but the missing guidance on optional parameters and response shape leaves gaps for a tool with this complexity.

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 description coverage is 100%, so the schema already explains all parameters. The description adds no parameter-specific meaning beyond listing audit fields that are output-related, not parameter-related. Baseline 3 is appropriate because the description doesn't compensate for anything the schema lacks.

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 explicitly states the tool performs a contract security audit and enumerates specific checks (honeypot, tax, ownership flags). It also distinguishes this tool from get_coin_info by directing price/market stats queries there, making the purpose unambiguous and sibling-aware.

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?

The arrow 'Price and market stats→get_coin_info' provides a clear alternative for a different use case, implying that this tool should be used specifically for security audits. This is explicit guidance on when to use another tool, similar to top-tier examples.

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

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

Annotations already provide readOnlyHint=false, destructiveHint=true, and idempotentHint=false, but the description adds no behavioral context beyond the core purpose. It does not explain why the tool might be destructive, what side effects occur, or any permissions/rate limits. Given the destructiveHint=true, the agent is left without guidance on what 'destructive' means here, so the description fails to enrich the transparency beyond annotations.

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 succinct fragments: 'Receivable assets on target chain for a source token. Same-chain trading→list_swap_tokens.' Every word contributes, no fluff, and it front-loads the core purpose. It is appropriately sized for a tool with a clear function.

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?

Despite 7 parameters and no output schema, the description is very minimal. It does not explain what 'receivable assets' means, how to identify the source token, what the response format looks like, or the significance of the openWorldHint and destructiveHint annotations. The mention of 'list_swap_tokens' helps orient the agent, but the overall context is insufficient for a tool of this complexity.

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% (all 7 parameters have descriptions), so the baseline is 3. The description itself adds no parameter-specific meaning; it doesn't explain how source_chain/source_address relate to the target chain or what 'receivable assets' implies for parameters. Since the schema already documents each parameter, the description is not required to repeat them, but it also doesn't add any semantic value.

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 'Receivable assets on target chain for a source token' clearly identifies the tool's output (list of receivable assets on a target chain) and resource (cross-chain bridge tokens). It also distinguishes from sibling 'dex_token_list_swap_tokens' via 'Same-chain trading→list_swap_tokens', but lacks an explicit verb like 'list' or 'get', making the purpose slightly less direct than the calibration high example.

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?

The description explicitly provides a usage alternative: 'Same-chain trading→list_swap_tokens.' This tells the agent when to use this tool (cross-chain) versus the sibling (same-chain), which is exactly the kind of guidance needed. It is concise and actionable.

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

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

Despite annotations (readOnlyHint:false, destructiveHint:true), the description adds little behavioral context. It doesn't explain any side effects, authentication needs, or the meaning of the destructive hint. The mention of tag is already covered by the schema, so no new behavioral information is provided.

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 extremely concise, with no wasted words. The bridge-target pointer is efficient and front-loaded, but the fragmented phrasing ('Tradable assets on a chain; tag selects...') makes it slightly less polished than a full sentence.

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 tool with 8 parameters and no output schema, the description is too sparse. It doesn't explain what the tool returns, prerequisites (e.g., wallet/account_id for favorites), or major use cases. It only addresses the bridge-token distinction, leaving many contextual gaps.

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%, so the baseline is 3. The description adds only a high-level note about tag, which duplicates schema info. It does not add meaning for other parameters like chain, search, wallet, or ignore_bridge.

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 identifies the resource as 'tradable assets on a chain' and hints that the tool lists tokens, with tag selecting favorites or recommendations. It distinguishes itself from the bridge-token sibling via an explicit pointer, but lacks an explicit verb like 'list' or 'get', making the action somewhat implicit.

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?

The description gives an explicit alternative: bridge targets should use list_cross_chain_bridge_tokens. However, it does not clarify when to use this tool over other token-related siblings (e.g., ranking, coin info), so guidance is partial.

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

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

Annotations indicate readOnlyHint=false and destructiveHint=true, which contradict the description's implication of a read-only ranking operation. The description does not disclose any destructive side effects or other behavioral traits, creating an annotation 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 extremely concise, using two short sentences to convey the tool's purpose and the alternative for single-token queries. 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?

While the description communicates the core ranking functionality and provides an alternative, it lacks any explanation of return format or pagination (no output schema), and fails to reconcile the contradicting destructiveHint annotation. This leaves gaps for a complete understanding.

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 description coverage is 100%, so the baseline is 3. The description restates the direction semantics already present in the schema ('direction selects gainers vs losers') but adds no new parameter-specific meaning.

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's function: ranking tokens by 24h price change, with 'direction' selecting gainers vs losers. It also distinguishes itself from sibling tool dex_token_get_coin_info by noting 'Single token→get_coin_info.'

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?

The description explicitly provides a when-not-to-use rule: if the user needs data for a single token, use 'get_coin_info' instead. This gives clear guidance on when to choose an alternative.

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

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

The description discloses a key non-obvious behavior: the transaction is not broadcast, which is critical safety information given the destructiveHint annotation (revoke is destructive when signed). It also clarifies the next step (signing) which beyond the annotations provides context that this is an intermediate step, not a final on-chain action.

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, front-loaded with the primary purpose, followed by a workflow hint. No filler or redundancy. Every word contributes to understanding the tool's role.

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?

Despite having 13 parameters and no output schema, the description captures the essential workflow: build, sign, and confirm. It does not explain every parameter (though the schema does), but it gives the tool's place in the transaction lifecycle. The lack of output schema is not an issue since the next step is signing, which is mentioned.

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?

The input schema has 100% coverage with descriptions for all 13 parameters. The description itself does not elaborate on parameter semantics beyond stating the tool builds approve/revoke transactions. Since the schema already covers parameter meanings, the description adds minimal value here, matching the baseline.

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 states a specific verb ('Build'), a specific resource ('ERC20/SPL approve or revoke tx'), and a critical scope qualifier ('does not broadcast'). This clearly distinguishes it from sibling tools like dex_tx_send_raw_transaction or dex_tx_swap_sign_approve by focusing on the construction/preview step.

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?

The description provides a clear usage context: build the tx with this tool, then sign with dex_wallet_sign_transaction after user confirmation. This gives the agent a workflow sequence. It does not explicitly name alternatives or exclusions, but the 'does not broadcast' statement implies it is not for sending.

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

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

The description indicates a read-only fetch operation, but the annotations declare destructiveHint=true. This is a direct contradiction: fetches are not destructive. The description does not disclose any destructive behavior or explain why the annotation is set, failing to provide the required behavioral transparency.

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 sentences: the first states the core action, the second gives a clear pointer to the sibling tool. No fluff, fully front-loaded, and every word 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?

Although the tool is simple and the description covers the basic operation, the annotation contradiction (destructiveHint=true) creates a significant completeness gap: the agent cannot trust the description's implied safety. Without an output schema, the description also doesn't hint at the return structure, but given the contradiction, the description is not sufficiently complete for safe invocation.

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?

The input schema covers all three parameters with descriptions (hash_id, mcp_token, from_wallet), giving 100% coverage. The description adds no extra parameter detail beyond mapping 'on-chain hash' to the hash_id parameter, so it relies on the schema. Baseline 3 applies.

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 states a specific action ('Fetch transaction detail by on-chain hash') and clearly distinguishes itself from the sibling tool 'swap_detail' by pointing to it for order-ID-based lookups. This is a precise verb+resource definition with explicit scoping.

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?

The description explicitly provides an alternative: '→ swap_detail for swap order detail by order ID.' This tells the agent when to use this tool vs. a different one, making the usage context unambiguous.

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

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

The description says 'Estimate,' which implies a read-only operation, but annotations set readOnlyHint=false and destructiveHint=true, directly contradicting that implication. No additional behavioral context is provided (e.g., side effects, permissions, or error conditions), so the description fails to disclose what the annotations suggest.

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 a single, front-loaded sentence with no redundant words. It efficiently communicates the core operation, making it concise and well-structured for the information it conveys.

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?

With no output schema and a 7-parameter input, the one-line description is insufficient. It doesn't explain the return format, mention the required mcp_token authentication context (beyond schema), or address the destructive annotation. The tool's operational expectations are left underspecified.

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?

All 7 parameters are fully described in the input schema (100% coverage), so the baseline is met. The description adds no extra parameter-level meaning beyond the schema, but it doesn't need to given the high schema coverage.

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 uses a specific verb ('Estimate') and identifies a distinct resource ('on-chain gas price and gas limit for a given tx'). This clearly differentiates it from sibling tools like transaction previews or RPC calls, and no other sibling handles gas estimation specifically.

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?

The description provides no explicit guidance on when to use this tool versus alternatives such as dex_tx_swap_quote, dex_rpc_call, or transfer previews. Usage context is only implied by the purpose statement, with no exclusions or alternative comparisons.

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

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

Annotations already indicate a destructive hint, and the description adds important behavioral context: the use of the latest blockhash to avoid 'Blockhash not found' and the urgency to sign immediately. It does not contradict annotations, though it could further explain what the returned unsigned transaction contains or the need for subsequent signing/broadcasting.

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 three short, front-loaded sentences that cover chain, action, blockhash strategy, and usage guidance without any filler. Every sentence adds value, making it concise and well-structured.

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 transaction-building tool with strong schema and annotations, the description is largely complete. It covers the Solana-only scope, blockhash freshness, signing urgency, and points to transfer_preview. It does not explicitly mention the next step (e.g., sign and send via dex_tx_send_raw_transaction), but 'Sign immediately' gives enough context for workflow inference.

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 each parameter already having a detailed description (e.g., amount, mcp_token, priority_fee_micro_lamports). The description adds no additional parameter-level semantics, relying on the schema to define parameters. This meets the baseline for adequate parameter documentation.

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's function with a specific verb and resource: 'build fresh native SOL unsigned tx with latest blockhash'. It explicitly limits to Solana and native SOL, distinguishing it from other transaction tools. The mention of 'avoids Blockhash not found' further clarifies its unique purpose.

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?

The description provides explicit usage guidance: 'Sign immediately' tells the agent to act promptly, and '→ transfer_preview for full summary first' names a sibling tool for pre-flight validation. It also scopes usage with 'Solana only', making it clear when this tool is appropriate.

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

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

The description states a read-only listing operation but the annotations declare destructiveHint=true and readOnlyHint=false, which is a direct contradiction. The description also does not disclose any behavioral traits beyond listing (e.g., pagination behavior or authentication requirements), leaving the agent confused about the tool's safety.

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 extremely concise: a single sentence with clear directional arrows to alternatives. Every word contributes to the purpose and usage guidance, with no unnecessary filler.

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 description gives the essential purpose and points to alternatives, but does not mention return format, pagination behavior, or auth requirements. The annotation contradiction further reduces trust. Given the rich schema (all params described) and the simplicity of a list operation, it is minimally adequate but clearly incomplete.

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_description_coverage is 100%, so the baseline is 3. The description adds no parameter-level semantics beyond the schema; it does clarify the tool is for transfers, which could loosely inform the use of the address parameter, but that's marginal value.

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's function: 'List wallet transaction history (transfers).' It uses a specific verb (List) and resource (wallet transaction history), and explicitly distinguishes it from sibling tools by directing to swap_history_list for swap/bridge orders and tx_detail for single tx by hash.

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?

The description gives explicit guidance on when to use this tool versus alternatives: '→ swap_history_list for swap/bridge orders. → tx_detail for single tx by hash.' This clearly defines the scope for this tool (transfers) and points to the right tools for other transaction types.

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

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

The description discloses a key behavioral trait: it requires user confirmation after a transfer preview, which goes beyond the annotations' destructive/readOnly hints. The 'Requires user confirmation' detail adds operational context, though it does not describe other behaviors like irreversibility or error handling.

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 sentences long, front-loaded with the action verb, and every clause adds value. The second sentence efficiently conveys the mandatory workflow without fluff or duplication of schema details.

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 destructive write operation with a rich parameter schema, the description covers the essential situational context (preview + signing prerequisites) and the action. It omits details about return values or failure modes, but given the high schema coverage and annotations, it remains nearly complete for a focused tool.

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?

With 100% schema description coverage, the schema already documents all 20 parameters thoroughly. The description adds no parameter-specific semantics beyond what the schema provides, fulfilling the baseline but not exceeding it.

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 a specific verb ('Broadcast') and resource ('a signed tx to the chain'), immediately distinguishing it from transaction signing or preview tools. It explicitly references the prerequisite signing tool, further clarifying its unique role in the workflow.

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?

The description provides explicit sequencing guidance: it must be used after user confirmation from transfer preview and after prior signing via dex_wallet_sign_transaction. This tells the agent when to invoke it, but it does not explicitly state when not to use it or contrast with alternative submission tools (e.g., dex_tx_swap_submit).

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

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

The description says 'Returns check-in fields', implying a read-only operation, but annotations set destructiveHint=true and readOnlyHint=false. No destructive side effects are disclosed, directly contradicting the annotations. This is an annotation 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?

Two short sentences deliver the core purpose and timing without fluff. The most critical info (what and when) is front-loaded, and every word 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?

No output schema exists, yet the description fails to explain what 'check-in fields' actually contain or what the agent should do with them. The sequencing guidance is helpful, but the contradiction with destructiveHint and lack of return-value detail leave significant gaps for a moderate-complexity tool.

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 description coverage is 100%, so baseline 3 applies. The tool description itself adds no parameter meaning beyond the schema, but the schema's param descriptions (especially mcp_token) are rich. No additional credit needed.

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 uses a specific verb ('Returns'), names the resource ('check-in fields'), and scopes it to a swap stage ('approve or swap'). It clearly distinguishes from sibling tools like dex_tx_approve_preview and dex_tx_transfer_preview by focusing on the swap workflow.

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?

The description explicitly states when to invoke this tool: 'Call after prepare and before terminal tx-checkin script.' This gives clear sequencing context that helps the agent understand the workflow position relative to dex_tx_swap_prepare and the terminal script.

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

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

The description says 'Fetch', which implies a read-only operation, but the annotations declare `destructiveHint: true`. This is a direct contradiction: the tool is described as a safe retrieval while the annotation suggests it may destroy or mutate data. The description also does not mention any side effects, authentication requirements, or rate limits, putting full burden on the description for transparency.

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 a single, focused sentence that immediately conveys the action and the source, followed by a useful pointer to an alternative tool. Every word earns its place, and the structure is front-loaded with the key purpose.

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 description adequately distinguishes the tool from siblings and explains its basic purpose, but it omits the critical behavioral implication from `destructiveHint: true`. It does not mention whether the fetch has side effects or what happens to the order, and there is no output schema to clarify return values. This makes the description incomplete for safe and correct usage.

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?

The input schema covers both parameters (`mcp_token` and `tx_order_id`) with detailed descriptions, giving 100% coverage. The description adds no parameter-specific information beyond the schema, so the baseline score of 3 is appropriate.

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 primary purpose ('Fetch swap order detail by order ID'), identifies the source ('from swap_submit'), and distinguishes itself from the sibling tool 'dex_tx_detail' by pointing to that tool for on-chain hash lookups. This is a specific verb+resource+scope with clear differentiation.

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 to use this tool when you have an order ID from swap_submit, and directs users to `tx_detail` for detail by on-chain hash. This provides clear when-to-use and an explicit alternative, which is excellent guidance for tool selection.

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

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

The description says 'List,' which implies a read-only operation, yet the annotations declare readOnlyHint=false and destructiveHint=true. This is a direct contradiction. The description does not add any behavioral context that reconciles this conflict, and annotations themselves are misleading. Score 1 per contradiction rule.

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-loaded with the primary action, and uses concise notation (→) to reference an alternative. Every word earns its place; no redundant or vague language.

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?

With 8 parameters, no output schema, and a contradictory annotation set, the description is too thin. It omits return format, error handling, or authentication context (though mcp_token schema partially covers auth). The contradiction further undermines completeness, leaving an agent uncertain about the tool's actual safety profile.

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 detailed parameter descriptions (e.g., mcp_token required, chain ID semantics, pagination defaults). The description adds no new parameter information beyond what the schema already provides, so the baseline 3 is appropriate.

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 a specific verb (List) and resource (swap/bridge order history), includes pagination and scope (single-chain and cross-chain), and distinguishes itself from the sibling tool tx_list by explicitly pointing to it for transfer history. This makes the purpose unmistakable.

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?

The description provides a clear alternative via '→ tx_list for transfer history,' which helps an agent decide when to use this tool versus a sibling. It does not offer explicit exclusions (e.g., when NOT to use), but the pointer to tx_list is practical and sufficient for basic differentiation.

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

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

The description adds value over annotations by clarifying the tool only stages server-side and does not sign or submit. However, with destructiveHint=true, the description provides no explanation of potential side effects (e.g., whether staging invalidates prior quotes or locks funds). It also omits authentication requirements (mcp_token) and session expiration, leaving some behavioral ambiguity.

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: first states the core action and return value, second clearly separates what it does not do. Every word earns its place; no fluff or redundancy. Front-loaded with the primary function.

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 tool with 12 parameters and no output schema, the description gives the essential purpose and sequencing but lacks guidance on next steps (what to do with swap_session_id), session validity, or handling of cross-chain specifics. The rich schema covers parameters, but the description doesn't explain the full workflow context, making it sufficient but not comprehensive.

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 description coverage is 100%, with highly detailed parameter descriptions (e.g., native_in/native_out critical warnings, user_wallet chain-specific rules, mcp_token requirement). The tool description itself adds no parameter-level detail beyond returning swap_session_id, so the schema carries the full burden. Baseline 3 is appropriate.

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 uses a specific verb 'Stage a swap session' and clearly distinguishes this tool from its siblings (quote, sign, submit) by stating it is 'server-side build only', returns swap_session_id, and explicitly 'Does not sign or submit'. This leaves no ambiguity about the tool's role in the swap flow.

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?

The instruction 'Call after quote confirmed by user' provides explicit timing guidance, and 'Does not sign or submit' implies the next steps are separate tools (sign/submit). However, it does not explicitly name the alternative sibling tools or mention when not to use this tool (e.g., if a quote is not confirmed).

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

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

The description states 'Returns swap route and pricing,' which implies a read-only operation, but the annotations declare destructiveHint=true. This is a direct contradiction. The description does not add any behavioral context that would resolve the discrepancy, and it contradicts the structured annotation.

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 sentences long, front-loaded with the core purpose, and every sentence earns its place. It efficiently covers purpose, workflow integration, and alternatives without any 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?

Given the extremely rich input schema (every parameter documented) and the tool's simple read-like purpose, the description is sufficient. It states what the tool returns and how to use it. The only gap is the contradiction with annotations, but that is handled under behavioral transparency. The description is complete enough for an agent to understand when and why to invoke this tool.

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 description coverage is 100%, so all 11 parameters are well-documented in the input schema. The description itself adds no parameter details beyond the schema, which meets the baseline for high coverage. No additional semantic value is provided.

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's purpose: 'Returns swap route and pricing.' It explicitly positions the tool within the workflow ('Call before swap_prepare') and distinguishes it from an alternative ('transfer_preview for direct token send'). This is specific and differentiates from siblings.

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?

The description provides clear usage guidance: call before swap_prepare, show the result to the user before proceeding, and use transfer_preview instead for direct token transfers. This explicitly states when and how to use the tool relative to alternatives.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, and the description adds the useful precondition 'Requires need_approved=true'. However, it does not disclose other behaviors such as whether the transaction is only signed or also submitted, or what side effects signing has beyond the implied state change. The added context is helpful but not rich; with annotations covering the safety profile, this is adequate but not exceptional.

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 a single, front-loaded sentence that begins with a '[write]' tag and immediately states the action. Every word contributes: the operation, the target, the context, and a key prerequisite. There is zero redundancy or filler.

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 description is adequate for a tool in a multi-step swap flow, but it lacks explicit guidance on what to do after signing or how this step fits with siblings like dex_tx_swap_submit. The schema partially compensates by referencing the prepare and checkin steps. Given the complexity of the flow, a mention of the next step would improve completeness, but it is not critically incomplete.

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 description coverage is 100%, so all parameters are already documented in the schema, including the checkin_token and swap_session_id sources. The description itself adds no parameter-specific meaning beyond the need_approved condition, which is not a parameter. This meets the baseline for high coverage but provides no extra value.

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's function: 'Sign the ERC20 approve tx for a staged EVM swap.' This uses a specific verb ('sign'), a specific resource ('ERC20 approve tx'), and distinguishes it from sibling tools like dex_tx_swap_sign_swap and dex_tx_swap_submit. The additional prerequisite (requires need_approved=true) adds precision without ambiguity.

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?

The description provides clear context for when to use the tool: it is for signing the approve transaction in a staged EVM swap, and specifically requires need_approved=true from the prepare result. This implies it is not for the swap signing itself, though it does not explicitly name alternatives or exclusions. The stated precondition offers actionable usage guidance.

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

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

Beyond the annotations (destructiveHint: true), the description discloses chain-specific behaviors: EVM requires sign_approve first if need_approved=true, while Solana generates a fresh signable payload. It also labels the operation as '[write]', adding context about side effects. This exceeds what annotations alone provide.

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 concise sentences, front-loaded with the core action ('[write] Sign the main swap tx for a staged session') and followed by essential chain-specific guidance. No wasted words; every sentence adds value.

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 multi-step signing tool, the description covers the key purpose and chain variations, and the schema handles parameter requirements. However, it does not mention what the tool returns (e.g., a signed transaction) or explicitly state that it must follow check-in/prepare steps, relying on sibling names and schema for that context. Still, it is reasonably complete for an agent familiar with the workflow.

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?

The input schema has 100% coverage with descriptions for all three parameters, so the description does not need to add parameter details. The description references need_approved=true which relates to a previous step, but the schema already fully documents the parameters. Baseline 3 is appropriate given full schema coverage.

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's function with a specific verb ('Sign') and resource ('main swap tx for a staged session'), distinguishing it from sibling dex_tx_swap_sign_approve by focusing on the main swap transaction. The chain-specific notes further clarify scope.

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?

The description provides context on when to use this tool: it is for staged sessions and explicitly mentions the prerequisite of calling sign_approve first on EVM when need_approved=true. It does not explicitly state when not to use it, but the chain guidance and naming of the sibling sign_approve give clear comparative usage hints.

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

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

Annotations already mark this as destructive/non-readonly, but the description adds valuable context: it does not sign, it is the final broadcast step, and it depends on prior signature steps. This goes beyond what annotations alone convey.

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 sentences, front-loaded with a '[write]' tag and a clear verb, and every word adds value. No fluff or redundant schema repetition.

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?

With a simple 2-param schema and no output schema, the description covers the essential context: it is the final broadcast step, requires prior signatures, and names the exact prerequisite tools. It lacks explicit mention of irreversibility, but destructiveHint covers that.

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?

The input schema is self-explanatory with 100% coverage for both parameters, so the description need not add param details. It provides no extra nuance beyond what the schema describes.

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 states a specific action ('Broadcast a staged swap to the chain') with a clear resource and distinguishes itself from the sign_approve and sign_swap sibling tools. This makes it immediately obvious what this tool does that others do not.

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?

The description explicitly says the tool does not sign and requires all signing steps to be complete, even naming the prerequisites (sign_approve for EVM+approval, then sign_swap). This provides clear sequencing and prevents misuse as an early step.

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

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

Annotation contradiction: description says 'Does not broadcast' and 'wait for user confirmation before signing,' implying a non-destructive build, while annotations declare destructiveHint=true. This directly undermines the tool's behavioral profile.

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 plus a redirect arrow, front-loaded with the action. No filler; every clause adds value.

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 13-parameter tool with no output schema, the description covers the essential workflow (no broadcast, confirmation requirement) and key return values (unsigned_tx_hex, txBundle). Parameter details are fully in the schema, but the annotation contradiction leaves a significant completeness gap.

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 description coverage is 100%, so baseline is 3. The description adds no extra parameter-level meaning; the schema already documents each parameter thoroughly.

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?

Clearly states it builds an unsigned transfer tx and displays a summary, using a specific verb and resource. The arrow to swap_quote/swap_prepare distinguishes it from token exchange 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?

Provides clear workflow context: does not broadcast, wait for user confirmation before signing, and redirects token exchange to swap tools. Lacks explicit 'use when' language but is sufficiently directive.

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

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

Annotations already convey readOnlyHint=false, destructiveHint=true, etc., so the bar is lowered. The description adds valuable context beyond annotations: it is 'EVM exact / EIP-3009 only', it does not require signing, and it may make an HTTP call requiring 402. It does not elaborate on destructive side effects, but given annotation coverage, this is sufficient.

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 moderately long but well-structured with a clear 1-2-3 flow and a conditional note. Every sentence adds necessary information—purpose, outputs, flow steps, and fallback behavior—so it earns its place without being verbose.

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?

With no output schema, the description compensates by naming the return fields (tx_checkin.message and x402_payment_required_b64) and explaining the dependency chain with dex_tx_x402_fetch. It covers the key behavioral edge case (omitted b64) and refers to parameters adequately. The only minor gap is not mentioning required auth beyond what the schema already states.

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 description coverage is 100%, and the schema already documents each parameter thoroughly, including the optional behavior of x402_payment_required_b64 and the requirement for mcp_token. The description adds workflow-level meaning (e.g., 'same url/body/headers') but does not introduce new parameter semantics beyond the schema.

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 uses a specific verb+resource combination: 'Prepare Gate Verify tx_checkin for x402' and clearly states the two key outputs (tx_checkin.message and x402_payment_required_b64). It also names the related tool dex_tx_x402_fetch and outlines the 3-step flow, which distinguishes it from other preview tools like dex_tx_swap_checkin_preview.

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?

The description explicitly outlines the workflow: this tool is step 1, followed by Gate Verify, then dex_tx_x402_fetch with specific fields. It also explains the conditional behavior when x402_payment_required_b64 is omitted. However, it does not explicitly state when NOT to use this tool or mention fallback alternatives beyond the named fetch tool.

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

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

Annotations show destructive/write behavior, but the description adds crucial details: automatic payment with x402, retry with PAYMENT-SIGNATURE, and the ability to skip the first HTTP call when x402_payment_required_b64 is supplied. It also discloses the mcp_token 403 requirement and network default.

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?

Three sentences pack in purpose, workflow, and domain-specific caveats. It is front-loaded and dense, though slightly long; each clause contributes necessary operational detail.

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 complex payment-aware HTTP tool with no output schema, the description provides essential prerequisites, auth requirements, retry behavior, and network defaults. It doesn't describe the final response format, but the procedural coverage is strong enough for correct invocation.

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 descriptions cover all 8 parameters (100%), so the baseline is 3. The tool description reinforces the relationship between checkin_token, preview, and x402_payment_required_b64 but adds little new parameter-specific meaning beyond what the parameter descriptions already state.

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 sends an HTTP request and automatically handles 402 Payment Required via x402, distinguishing it from the sibling preview tool. The [write] prefix and explicit flow make the purpose unambiguous.

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 requires Gate Verify tx_checkin before signing, tells the agent to use dex_tx_x402_checkin_preview first for EVM EIP-3009, and gives CoinGecko-specific rules (omit api key, default network). This provides strong when-to-use and procedural guidance.

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

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

Annotations already indicate a destructive, non-read-only operation. The description adds useful behavioral constraints: the session must be a standalone Gate session and the UID must come from the OAuth login result. It doesn't elaborate on what happens if a binding already exists, but the annotation's destructive hint partially covers this, and the added OAuth constraint goes beyond annotation info.

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 extremely concise: two short sentences with the action first, followed by a condition and a pointer to the alternative. Every word adds value, no filler.

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 tool with full schema coverage and no output schema, the description covers the core purpose, a key precondition, and the alternative for rebinding. It doesn't explicitly mention the required mcp_token, but that is in the schema. The only minor gap is a lack of detail about failure behavior or existing bindings, but overall it's sufficient for an agent to use the tool correctly.

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 description coverage is 100%, so the schema already explains both parameters thoroughly. The description reinforces the gateUid constraint but doesn't add new parameter meaning beyond what the schema states. Baseline 3 is appropriate.

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 action: 'Bind Gate exchange UID to session' with a specific verb and resource. It also distinguishes itself from the sibling tool 'replace_binding' by noting that rebinding is handled there, making the purpose unambiguous.

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 provides explicit usage conditions: 'Standalone Gate session only' and 'gateUid must equal login_result.gate_uid from Gate OAuth'. It also names the alternative for rebinding ('→ replace_binding to rebind'), giving clear guidance on when to use this tool vs. its sibling.

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

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.

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

The description 'Returns current Gate UID binding' strongly implies a read-only operation, but annotations declare readOnlyHint=false, idempotentHint=false, and destructiveHint=true. This is an annotation contradiction and leaves the tool's true behavior unclear.

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 a single sentence with no filler, front-loading the purpose and scope immediately. It earns its place with zero 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?

There is no output schema, so the description should clarify the return value, but it only vaguely says 'current Gate UID binding'. The contradictory annotations add behavioral uncertainty, and there is no context about the Gate UID concept or how this fits into the authentication flow.

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 description coverage is 100% for the single parameter mcp_token, including its requirement and the 403 error consequence. The description adds no additional parameter semantics beyond the schema, so the baseline score of 3 is appropriate.

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 uses a specific verb 'Returns' with a clear resource 'Gate UID binding' and scope 'session wallet', making it easy to distinguish from sibling tools like dex_wallet_bind_exchange_uid or dex_wallet_replace_binding.

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?

No guidance is provided on when to use this tool versus alternatives such as binding or replacing a Gate UID. There is no mention of prerequisites, exclusions, or specific scenarios where this call is appropriate.

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

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

Annotations include destructiveHint=true, yet the description gives no indication of side effects. It does not contradict annotations, but also adds no behavioral context. The bar is lower because annotations exist, but the lack of any mention of destructive behavior is notable.

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?

One sentence, front-loaded with the core function, and ends with a useful pointer to the sibling tool. 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?

Given the simple listing nature and rich schema, the description is nearly sufficient. It explains what is returned (balances and prices) and suggests the appropriate alternative for summaries. Missing details about output pagination format, but that's minor.

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%, so the description adds little beyond the schema. The mention of filtering by network_keys mirrors the schema description. No extra semantic value is provided.

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 lists token balances and prices with pagination, and explicitly distinguishes it from get_total_asset for portfolio summaries. The verb 'get' plus resource 'token list' is specific and unambiguous.

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?

Provides explicit guidance: use this for detailed token balances/prices, and use get_total_asset only for portfolio summary. This directly names an alternative and clarifies the boundary between the two tools.

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

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

The annotations declare destructiveHint=true and readOnlyHint=false, but the description indicates a simple read-only portfolio value query. This direct contradiction makes the behavioral transparency score 1, as the description contradicts the structured metadata.

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 extremely concise, using two short phrases that immediately convey the purpose and point to the alternative. Every word earns its place with no unnecessary filler.

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?

While the core purpose is stated, the contradiction with destructiveHint leaves the context incomplete. The description does not address the safety or non-destructive nature of the operation, making it inadequate given the misleading annotations. Minimal detail on return format or auth also reduces completeness.

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 description coverage is 100%, with both parameters explained in the schema. The description adds no extra parameter semantics, so the baseline score of 3 applies.

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 total portfolio value and 24h change. The arrow to get_token_list distinguishes it from the per-token sibling, making the purpose specific and unambiguous.

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?

Explicitly directs the user to get_token_list for per-token balance detail, providing an alternative for a related use case. This implies the tool is for aggregate portfolio value, not per-token detail, offering clear guidance on when to use it.

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

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

Annotations mark destructiveHint=true, and the description adds concrete side-effect details: with for_withdraw_to_exchange or for_gate_oauth_bind, it starts Gate OAuth when gateUid is missing. This goes beyond the annotation by specifying the trigger condition and behavior. No contradiction with annotations.

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, front-loaded with return values, and every clause provides information about the tool's core behavior and side effects. 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 description lists the return fields (walletAddress, walletType, gateUid) and covers the OAuth side effect, which is sufficient given the annotations and parameter schema. It could elaborate on walletType possible values or OAuth flow details, but these are not essential for selecting and invoking the tool.

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 description coverage is 100%, so the baseline is 3. The tool description references the two boolean flags but only reiterates what the schema already states, adding no new parameter-level meaning.

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 walletAddress, walletType, and gateUid, and mentions when it triggers OAuth, which distinguishes it from sibling tools like dex_wallet_get_addresses. However, it does not explicitly state the broader 'classify wallet' purpose beyond the return values.

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?

The description provides no explicit guidance on when to use this tool versus alternatives such as dex_wallet_bind_exchange_uid or dex_wallet_google_gate_bind_start. The presence of boolean flags implies use cases, but there is no direct comparison or exclusionary language.

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

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

Annotations already indicate a destructive, state-changing operation. The description adds context by specifying that this initiates an OAuth flow specifically for Google sessions, and that mcp_token remains unchanged after polling. It does not contradict the annotations.

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, front-loaded with the core purpose, 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 description explains the action but omits details about the expected response or next steps in the flow (e.g., which poll to call after starting). Given no output schema, this leaves some ambiguity for an agent.

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?

The input schema covers 100% of the parameter (mcp_token) with its own description, so the tool description adds no additional parameter semantics. Baseline 3 is appropriate when the schema fully documents parameters.

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's function: it starts a Gate OAuth flow to bind a Gate exchange UID to the current session. The 'Google sessions only' qualifier adds scope and distinguishes it from sibling binding/login 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?

The description provides a clear usage context ('Google sessions only') and notes a key behavioral fact ('mcp_token stays unchanged after poll'). However, it does not explicitly state when to use this tool over alternatives like dex_wallet_bind_exchange_uid or dex_auth_gate_login_start.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the description doesn't need to re-establish the write nature. It adds valuable context about session restrictions and the freshness requirement for the OAuth token, which are non-obvious behavioral constraints not predictable from annotations alone.

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 three short sentences, each carrying distinct information: the action, the critical requirement, and the blockers. It avoids redundant phrasing and gets straight to the point, making it easy for an agent to parse quickly.

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?

Together with the exhaustive parameter schema and safety annotations, the description covers the tool's purpose, prerequisites, and exclusions. It doesn't describe post-action effects or return values, but for a simple two-parameter destructive operation with no output schema, this is sufficient for an agent to invoke it correctly.

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?

The input schema provides 100% coverage for both parameters, fully describing newUid and mcp_token with their constraints. The description merely restates the newUid requirement from the schema without adding genuinely new parameter-level detail, so the baseline score of 3 is appropriate.

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 'Rebind Gate exchange UID,' a specific verb+resource that clearly distinguishes this from the sibling dex_wallet_bind_exchange_uid (bind vs. rebind). The '[write]' marker and the focus on replacing an existing UID make the purpose unambiguous.

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 states core prerequisites ('newUid must equal login_result.gate_uid from a fresh Gate OAuth') and exclusions ('Blocked for gate_mcp/gate_quick sessions and Google sessions'). It doesn't explicitly name an alternative for first-time binding, but the context clearly implies when rebinding is appropriate versus initial binding.

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

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

Annotations already indicate readOnlyHint=false, destructiveHint=true, and idempotentHint=false. The description adds operational context by tagging '[write]' and requiring 'checkin_token' from tx-checkin, which is not conveyed by annotations. No contradiction exists, but side effects or return behavior are not disclosed.

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 a single, front-loaded sentence that includes the operation, a write marker, the auth requirement, and a pointer to an alternative tool. Every phrase earns its place, with no redundant or extraneous text.

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 signing tool with no output schema, the description covers the essential purpose, the mandatory checkin_token prerequisite, and the alternative for raw transaction signing. It does not explain the return format or potential side effects, but the overall complexity is moderate and the annotations fill in safety semantics.

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 description coverage is 100%, so the schema carries the parameter meaning. The description adds minimal value: it clarifies the message size ('32-byte hex') and reiterates the checkin_token source. It does not add detail beyond what the schema already provides for chain or mcp_token.

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 uses a specific verb and resource: 'Sign a 32-byte hex message with wallet key.' It clearly distinguishes from the sibling tool 'dex_wallet_sign_transaction' by adding '→ sign_transaction for raw tx signing.' The purpose is unambiguous.

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?

The description explicitly states a prerequisite ('Requires checkin_token from terminal tx-checkin') and directs users to an alternative for a different use case ('sign_transaction for raw tx signing'). It does not exhaustively enumerate when to avoid this tool versus all other signing siblings, but provides clear context for the primary decision.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the write nature is known. The description adds behavioral context beyond annotations: it requires user confirmation and a checkin_token from a prior tx-checkin step, and it positions the tool as a pre-broadcast step. This is valuable additional information.

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 concise and structured: action, prerequisite, next step. It is front-loaded with the verb and resource. The [write] tag is redundant with annotations but does not harm clarity. A score of 4 reflects the efficient use of space with minor redundancy.

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 description is complete for a signing tool: it explains the prerequisite (checkin_token, user confirmation), the action (sign raw unsigned transaction), and the next step (broadcast). It does not detail return values, but none are required given the flow and no output schema.

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 description coverage is 100% with all parameters documented, so the description does not need to add parameter details. The description mentions checkin_token as a requirement, but this is already in the schema. No additional semantic value is added beyond what the schema provides.

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 action: 'Sign a raw unsigned transaction.' It identifies the specific resource (raw unsigned transaction) and distinguishes from sibling tools like dex_tx_swap_sign_swap and dex_wallet_sign_message by noting the requirement for checkin_token from tx-checkin and the subsequent broadcast step.

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?

The description provides usage context by stating that user confirmation and a checkin_token are required, and explicitly points to the next tool (dex_tx_send_raw_transaction) for broadcasting. It does not explicitly mention when not to use it, but the workflow is clearly implied.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true; the description's '[write]' label reinforces but does not extend this. It adds the useful behavioral note that uid is session-resolved, but does not disclose side effects like whether a new address is generated or previous addresses invalidated. Thus it provides limited added transparency beyond annotations.

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, each carrying essential information; the first states the action, the second packs two critical constraints. No wasted words, and the key info is front-loaded.

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 tool with 5 parameters and no output schema, the description covers the core purpose, the most important constraint (amount threshold), and the session-bound behavior, while the schema handles parameter details. It does not describe the return value, but that's implied by 'Fetch'. It is sufficient for an agent to invoke correctly.

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%, so the baseline is 3. The description adds a meaningful negative constraint ('do not pass uid—it is resolved from the session') and reiterates the amount threshold, giving the agent extra guidance beyond the schema. This justifies a 4.

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?

Description uses specific verb 'Fetch' and identifies exact resource 'Gate exchange deposit address' scoped to the session-bound Gate UID, clearly distinguishing it from sibling tools like dex_wallet_get_addresses. The purpose is unambiguous and specific.

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?

Provides clear context: this tool is for retrieving a Gate deposit address tied to the session-bound UID, and includes direct constraints (amount ≥ min_deposit_amount, do not pass uid). However, it does not explicitly list alternative tools or when not to use it, so it falls short of a 5.

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