dexe-mcp

Unstake tokens/NFTs from a DAO

dexe_vote_build_withdraw

Read-only

Builds calldata to unstake deposited governance tokens from a DeXe GovPool without broadcasting, preparing a wallet-signed withdrawal; voted tokens stay locked until proposal execution.

Instructions

Builds calldata; does not broadcast. GovPool.withdraw(receiver, amount, nftIds) — unstakes deposited governance tokens. Tokens you voted with stay locked until that proposal is executed.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "govPool": "<govPool>",
      "receiver": "<receiver>",
      "amount": "<amount>"
    },
    "name": "dexe_vote_build_withdraw"
  }
}

Input Schema

Name	Required	Description
`amount`	Yes	Governance token to unstake, in that token's own decimals. RAW base units, digits only ('1500000000000000000' = 1.5 at 18 dec); '1.5' is REJECTED — scale it, or use dexe_proposal_create
`nftIds`	No	Your governance NFT token ids, decimal; [] for ERC20-only DAOs.
`chainId`	No	Chain this payload targets: 56 mainnet, 97 testnet. Default: the configured chain.
`govPool`	Yes	DAO GovPool address (dexe_dao_registry_lookup).
`receiver`	Yes	Address the unstaked tokens/NFTs are sent to.

Output Schema

Name	Required	Description
`payload`	Yes
`warnings`	No
`advisories`	No	Deprecated — use warnings.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.37.1Nov 11, 2026

TDQS

A4/5.0

Behavior4/5

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

The description is consistent with readOnlyHint=true and reinforces it by clarifying that only calldata is produced, not a state change. It adds a real behavioral caveat beyond annotations — tokens used in voting remain locked until the proposal executes — though it says nothing about approval prerequisites or what the produced payload looks like.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the most decision-relevant fact (no broadcast), then the contract call, then the locking caveat. Nothing is wasted or restated.

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 an output schema present and full parameter coverage, the definition covers what an agent needs to call it and understand its limits. A one-clause pointer to the execute/broadcast step would close the only remaining gap.

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%, so amount units, nftIds defaults, chainId values, and govPool/receiver addresses are already fully documented. The call signature echoes the parameter order, which is mildly useful, but the description adds no semantics the schema lacks.

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 verb and resource ('Builds calldata', `GovPool.withdraw(receiver, amount, nftIds)` — unstakes deposited governance tokens) and immediately scopes it against broadcasting. An agent can tell this constructs a payload rather than moving funds.

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

Usage Guidelines3/5

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

The 'does not broadcast' clause implies a follow-up execute step, but no sibling is named and there is no explicit when-to-use/when-not guidance. The locked-tokens note gives context for outcome, not routing between tools.

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

Deploy Server