Skip to main content
Glama
Sign In
dexe-mcp

dexe-mcp

by edward-arinin-web-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Vote on an external proposal

dexe_vote_build_vote
Read-only

Builds unsigned voting calldata for a DeXe GovPool proposal, wrapping the vote in a single-element multicall so SphereX-protected pools accept it. Requires staked or delegated power first; does not broadcast.

Instructions

Builds calldata; does not broadcast. Emits GovPool.multicall([vote(proposalId, isVoteFor, amount, nftIds)]) — the single-element multicall the frontend sends, because SphereX-protected pools revert a raw top-level vote(). Needs staked or delegated power first (dexe_vote_build_deposit).

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>",
      "proposalId": "<proposalId>",
      "isVoteFor": "<isVoteFor>",
      "amount": "<amount>"
    },
    "name": "dexe_vote_build_vote"
  }
}

Input Schema

NameRequiredDescriptionDefault
voterNoYour address. When set, the deposit-lock warning is checked against your live power and shown only if your tokens really are locked.
amountYesYour staked/delegated governance token power to cast, 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
nftIdsNoYour governance NFT token ids, decimal; [] for ERC20-only DAOs.
chainIdNoChain this payload targets: 56 mainnet, 97 testnet. Default: the configured chain.
govPoolYesDAO GovPool address (dexe_dao_registry_lookup).
isVoteForYestrue = vote FOR, false = vote AGAINST.
proposalIdYesOn-chain proposal id, 1-indexed decimal (dexe_proposal_list).

Output Schema

NameRequiredDescriptionDefault
payloadYes
warningsNo
advisoriesNoDeprecated — use warnings.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.37.1

TDQS

A4.3/5.0
Behavior5/5

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

The readOnlyHint annotation is consistent with 'does not broadcast', and the description goes well past it: it names the exact on-chain call shape, explains the non-obvious reason for the single-element multicall (SphereX-protected pools revert a raw vote()), and states the staking prerequisite. These are behavioral facts an agent could not derive from annotations or schema.

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?

Dense but front-loaded: the 'does not broadcast' contract comes first, then the call shape, then the prerequisite. The 'single-element multicall the frontend sends' clause is arguably extra, but it justifies the unusual encoding and so earns its place.

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 calldata-building tool with a full output schema and complete parameter docs, the description covers purpose, prerequisite ordering, and why the encoding is non-obvious. The remaining gap is minor: it never says what the agent should do with the returned calldata (which sibling broadcasts it), leaving that step to inference.

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 the schema already carries parameter meaning, including the RAW base-unit constraint on `amount`. The description adds only that nftIds/amount flow into the vote(...) argument list; no extra format, bounds, or defaulting guidance beyond the schema. Baseline 3 is appropriate.

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' for a vote) and immediately disambiguates scope from the broadcast step; the emitted call signature `GovPool.multicall([vote(proposalId, isVoteFor, amount, nftIds)])` pins down exactly what payload is produced. An agent can separate this from dexe_vote_build_deposit or dexe_proposal_vote_and_execute without opening a schema.

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?

Gives an explicit prerequisite ('Needs staked or delegated power first') and routes to the sibling that satisfies it (dexe_vote_build_deposit). It also signals when-not (this path is preferred over a raw top-level vote() on SphereX-protected pools). It stops short of explicitly contrasting with the broadcast/execute sibling, so the alternative is implied rather than named.

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

Deploy Server

Other Tools