dexe-mcp

Connect a wallet by QR

dexe_wc_connect

Starts a WalletConnect session and renders a scannable ASCII and PNG QR code so your phone signs and broadcasts transactions without exposing a private key.

Instructions

Writes to a remote service. Starts a WalletConnect session and renders a scannable QR (ASCII + PNG). RECOMMENDED signer — the phone signs and broadcasts, so no private key touches this machine. Poll dexe_wc_status until connected. In DEXE_SIGNER_MODE=unattended a hot key signs instead.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "dexe_wc_connect"
  }
}

Input Schema

Name	Required	Description	Default
`chainId`	No	Chain to request in the session namespace. Defaults to the MCP's default chain.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.37.1Nov 11, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=false / destructiveHint=false; the description adds substantial context beyond them: that the call writes to a remote service, opens a session, emits both ASCII and PNG QR output, exposes no private key, requires polling to reach `connected`, and behaves differently under DEXE_SIGNER_MODE=unattended. The stated write behavior is consistent with readOnlyHint=false.

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?

Three short sentences with no filler, and the key routing guidance is front-loaded. Minor deduction because the leading 'Writes to a remote service' is generic framing that delays the actual action (starting the WalletConnect session / QR) by one clause.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-optional-param tool with no output schema, it covers what the call does, what it returns (QR in two formats), and what to do next. What is missing is failure/expiry behavior — how long the QR is valid, what happens if the session times out, and how to recover — which matters for a session-establishing tool.

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 single optional `chainId` is already documented in the schema as the chain requested in the session namespace, defaulting to the MCP's default chain. The description adds nothing about chainId, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific action and artifact: 'Starts a WalletConnect session and renders a scannable QR (ASCII + PNG).' This distinguishes it from dexe_wc_status (polling) and dexe_wc_disconnect, which the description explicitly references, so an agent can route correctly without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use rationale ('RECOMMENDED signer — the phone signs and broadcasts, so no private key touches this machine'), the follow-up action ('Poll dexe_wc_status until `connected`'), and an environment-based exception ('In DEXE_SIGNER_MODE=unattended a hot key signs instead'). This is close to a complete decision procedure.

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

Deploy Server