Skip to main content
Glama

Gate DEX MCP

by io.github.gateio-dev

dex_tx_x402_checkin_preview

Destructive

Prepare Gate Verify tx_checkin for x402 (EVM exact / EIP-3009 only): returns tx_checkin.message (64-hex digest) and x402_payment_required_b64 without signing. Flow: 1) this tool 2) Gate Verify tx_checkin with returned tx_checkin fields 3) dex_tx_x402_fetch with same url/body/headers, checkin_token, and the same x402_payment_required_b64. If x402_payment_required_b64 is omitted, performs one HTTP call and requires HTTP 402.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesSame URL as dex_tx_x402_fetch
bodyNoOptional request body
methodNoHTTP method; default GET
headersNoOptional JSON object of request headers
mcp_tokenNoMCP session token obtained from login (dex_auth_google_login_poll or dex_auth_gate_login_poll). MUST be provided in every call to this tool after login; omitting it will result in 403
x402_preferred_networkNoSame as dex_tx_x402_fetch
x402_payment_required_b64NoOptional: PAYMENT-REQUIRED header base64; when omitted, one outbound request is made and must return 402

TDQS

A4.1/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All Gate DEX MCP toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.4/5.0
Disambiguation4/5

Most tools have clear, distinct roles (auth flows, market data, swap stages, wallet operations). A few ambiguities exist, such as dex_tx_get_sol_unsigned vs dex_tx_transfer_preview and dex_agentic_report's name not matching its description, but overall agents can reliably select the correct tool.

Naming Consistency3/5

Naming is inconsistent: while all tools share the dex_ prefix and category segments, some use get_*, others list_*, and several are noun phrases (dex_chain_config, dex_tx_gas, dex_tx_detail). Auth tool ordering also varies (gate_login_start vs login_gate_wallet), making the pattern less predictable.

Tool Count2/5

With 47 tools, the server is over-scoped and burdensome for agents to navigate. Even though the broad DEX domain justifies many features, this exceeds the 25+ threshold for 'too many' and could benefit from consolidation into fewer, higher-level tools.

Completeness4/5

The tool set comprehensively covers DEX workflows: auth, market data, token info, wallet balances, transfer/swap pipeline, cross-chain bridge, and x402 payments. Minor gaps include lack of explicit swap cancellation or withdrawal execution, but these are secondary to the core functionality.

Resources