dexe-mcp
Provides DeXe Protocol governance tools on BNB Chain, including DAO deployment, all proposal types, voting, delegation, execution, OTC token sales, treasury and subgraph reads, reporting, and transaction simulation.
Handles IPFS metadata for DAO proposals, including reading from public gateways and uploading metadata via Pinata when configured.
Supports reading, building, simulating, and decoding governance operations against OpenZeppelin Governor DAOs.
Provides tools for interacting with Compound-Bravo/OpenZeppelin Governor DAOs on Optimism, including proposal reads, transaction building, simulation, and decoding.
Enables connecting a wallet through WalletConnect so transactions can be approved on a phone and broadcast without storing a private key on disk.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@dexe-mcp what's in the treasury of my DAO on BSC?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
dexe-mcp
An MCP (Model Context Protocol) server for DeXe Protocol governance on BNB Chain, with an additional generic surface for OpenZeppelin and Compound-Bravo Governor DAOs (Uniswap, Compound, Optimism).
It exposes 173 typed tools in 19 groups: DAO deployment, all 33 DeXe proposal types, voting, delegation, execution, OTC token sales, treasury and subgraph reads, one-call DAO reporting, IPFS metadata, transaction simulation, multi-agent orchestration, and diagnostics. Any MCP client that can launch a local command can use it — Claude Code, Claude Desktop, Cursor, Codex CLI, or a custom agent. The package also ships a read-only edition, dexe-mcp-read (54 tools that only read, on stdio or over HTTP for remote clients) — see Read-only edition.
Writes are calldata-first: tools return a { to, data, value, chainId } payload for your own wallet to sign. Broadcasting from the server is opt-in, and a human confirms every transaction: through WalletConnect (approved on your phone; no key on disk — the default) or an encrypted local keystore (each batch approved with its password on a local page). A plaintext hot key that signs unattended exists for bots and CI only, testnet by default. docs/SIGNING.md explains the modes and what each protects against.
Install in Claude Code
Two commands, typed inside Claude Code:
/plugin marketplace add edward-arinin-web-dev/dexe-mcp
/plugin install dexe@dexe-mcpThen ask:
"Show the treasury of
0x…on BSC."
Reads work with no configuration: on-chain data, subgraphs, the DeXe backend, and IPFS all have public defaults, and WalletConnect signing is available immediately (dexe_wc_connect). Eight skills install with the plugin — dexe-setup, dexe-create-dao, dexe-create-proposal, dexe-vote-execute, dexe-otc, dexe-staking, dexe-report (zero-config), and dexe-agent-team (needs DEXE_TOOLSETS=core,agents and hot keys in DEXE_SIGNER_MODE=unattended).
To create DAOs or proposals, or to broadcast transactions, run /dexe-setup — it walks through the two keys that unlock those paths (a Pinata token for IPFS uploads, a signer) and writes them to the .env the server actually loads (~/.dexe-mcp/.env for a plugin install).
Using Cursor, Claude Desktop, Codex CLI, another local MCP client, or the terminal? See docs/INSTALL.md.
Related MCP server: BNB Chain MCP Server
Read-only edition (dexe-mcp-read)
A second binary in the same package serves only the 54 tools that read: DAOs, proposals, votes and voters, treasury, members, delegation, validators and experts, token sales, staking, protocol statistics, and external Governors. It cannot sign, send, upload or build transactions — that code is not even loaded into its process — and it keeps nothing between calls. It reads with zero configuration, and ignores and drops any signing or upload key it finds in a shared .env.
claude mcp add dexe-read -- npx -y -p dexe-mcp dexe-mcp-read # Claude Code{ "mcpServers": { "dexe-read": { "command": "npx", "args": ["-y", "-p", "dexe-mcp", "dexe-mcp-read"] } } }dexe-mcp-read serve-http serves the same tools over MCP Streamable HTTP for remote clients (Claude.ai custom connectors, ChatGPT developer mode); it ships as a Docker image recipe and is pre-release. Operators: docs/REMOTE.md.
Quickstart (other MCP clients)
Reads need no environment at all. The steps below set up uploads and signing.
Wizard path:
npx -y dexe-mcp@latest --version # what you are about to run
npx -y dexe-mcp@latest init # interactive setup: network, Pinata, signer mode
npx -y dexe-mcp@latest doctor # verifies RPC, Pinata, IPFS gateway, subgraph--help and --version print and exit without loading any environment. init writes ~/.dexe-mcp/.env (a source checkout writes the repo-root .env) and prints a client-config snippet to paste. doctor checks every recognized DEXE_* variable and reports pass/warn/fail with remediation hints; warnings are normal on a zero-config install and it exits 0 — pass --strict (or set DEXE_DOCTOR_STRICT=1) to make warnings exit 1 in CI, and expect 2 on a real failure. Full runbook: docs/SETUP.md; check reference: docs/DOCTOR.md; upgrade notes: docs/MIGRATION.md.
Already installed globally? Use dexe-mcp init instead — do not mix the two. A global install shadows npx dexe-mcp@<version>, which then silently runs the old code (docs/INSTALL.md).
Manual path — register with your MCP client (.mcp.json, claude_desktop_config.json, Cursor settings):
{
"mcpServers": {
"dexe": {
"command": "npx",
"args": ["-y", "dexe-mcp@latest"]
}
}
}With a global install, the same block is { "command": "dexe-mcp" }. Add an env block only if you want to override the defaults:
{
"mcpServers": {
"dexe": {
"command": "dexe-mcp",
"env": {
"DEXE_RPC_URL_MAINNET": "https://bsc-dataseed.bnbchain.org"
}
}
}
}The env block is optional — without it the server falls back to a public BSC RPC, which is rate-limited and suitable for evaluation; set your own endpoint for production use.
Windows: if your MCP client can't resolve the
dexe-mcpshim on PATH, point it at the script directly:{ "command": "node", "args": ["<npm root -g>/dexe-mcp/dist/index.js"] }
Example calls (all four are in the default profile — no DEXE_TOOLSETS, no env):
// The whole DAO in one call: identity, treasury, members, delegation,
// turnout, and everything with a deadline
dexe_dao_report({ govPool: "0x...", chainId: 56 })
// ...and on the next run, only what moved since the previous one
dexe_dao_report({ govPool: "0x...", chainId: 56, since: "last" })
// Enumerate every proposal type the server can build
dexe_proposal_catalog({ category: "all", implementedOnly: true })
// Create a proposal of ANY catalog type — proposalType + params
dexe_proposal_create({
govPool: "0x...",
title: "Pay the audit invoice",
proposalType: "token_transfer",
params: { token: "0x...", recipient: "0x...", amount: "1000.0" }
})dexe_proposal_create covers every on-chain catalog type; the single-purpose dexe_proposal_build_* builders (raw calldata, one tool per type) need DEXE_TOOLSETS=core,proposals.
Each write tool returns a TxPayload you pass to your wallet. To let the server broadcast instead, connect a wallet over WalletConnect (dexe_wc_connect), or create an encrypted key with npx dexe-mcp key create and set DEXE_SIGNER_MODE=keystore — each batch (and each off-chain login or Safe signature) then opens a local approval page that asks for its password, or you approve in a terminal with npx dexe-mcp approve. That enables the composite flows dexe_proposal_create, dexe_proposal_vote_and_execute, and dexe_tx_send. A hot DEXE_PRIVATE_KEY signs only with DEXE_SIGNER_MODE=unattended (bots, CI); see docs/SIGNING.md.
Requirements
Node.js ≥ 20.12 with a working
npm(process.loadEnvFile, used to read.env, needs 20.12+). Check withnode -v.Git — only for the optional dev toolset (
dexe_compile/dexe_test/dexe_lint), which shallow-clones DeXe-Protocol on first use. SetDEXE_PROTOCOL_PATHto use an existing checkout. Reads, builders, and deploys do not use it.
Features
DeXe governance coverage: the 33 proposal types (24 external, 4 internal validator, 5 off-chain), validator chamber, expert delegation, multi-tier OTC sales with merkle whitelists.
Calldata-first key model: no private key is required for any build tool. Broadcasting is a separate, explicit opt-in.
Zero-config reads: public RPC, subgraph, backend, and IPFS gateway defaults let read tools work out of the box — including
dexe_dao_report, which returns a whole DAO (identity, treasury, membership, delegation, turnout, deadlines) in one call, and can diff itself against its own previous run. docs/REPORTING.mdExternal Governor support: 18
dexe_gov_*tools read, build, simulate, and decode against OpenZeppelin and Bravo Governors; new DAOs are a config entry.Multi-agent orchestration: run several wallets as personas against one DAO.
signerKeyon the write composites (dexe_dao_create,dexe_proposal_create,dexe_proposal_vote_and_execute,dexe_tx_send, the OTC buyer composites) chooses which keyring wallet signs;dexe_agents_fundpreviews a funding plan and only moves value onconfirm: true, under an enforced per-agent cap and a rolling 24-hour spend budget;dexe_agents_ledgerreports which persona did what and what it cost. A fleet of hot keys sitting in.envis a loaded gun — read docs/AGENTS.md for the safety model, what enforces versus what only advises, and the testnet-first workflow, before pointing personas at a DAO that holds real money.Tested on-chain: a 69-scenario multi-agent harness exercises the builders against BSC-testnet fixture DAOs — build-only checks for all proposal types, full propose → vote → execute lifecycles for the broadcast paths.
MIT-licensed, no telemetry, no hosted dependency — requests go only to endpoints you configure.
Example applications
Verified, prompt-level scenarios live in docs/USE_CASES.md — each with the exact tools it exercises and on-chain evidence. Highlights:
Basics — create a DAO with its own token in one call; propose → vote → execute; join an existing DAO.
Q&A over live data — "does DAO X have validators?", whale maps, TVL charts, delegation graphs, per-proposal voter lists. (Since v0.31.0 the reporting reads are in the default profile and need no keys:
dexe_dao_report,dexe_graph_query,dexe_graph_schema, DAO list/members/stats, token holders, delegation map.dexe_dao_report'sturnoutsection already carries per-proposal voter counts. The long-tail reads — named voter lists (dexe_proposal_voters), validator rosters, per-user activity, local experts, protocol stats, NFTs, inbox/forecast/risk — still live in thereadprofile: setDEXE_TOOLSETS=core,read(orfull), or askdexe_contextwhich sets are off and how to enable them.)Automation — pair reads with your agent's scheduler (
/loop,/schedule): a scheduleddexe_dao_reportwithsince: "last"reports only what moved since its own previous run, plus proposal watchdogs, daily governance digests (dexe_user_inbox), quorum trackers, treasury monitors, policy-based delegate agents.Analysis — decode + risk-assess any proposal (quorum safety, treasury at risk, who profits); due-diligence a DAO before buying in; simulate before broadcasting.
Advanced ops — make the DAO call ANY external contract (
custom_abi), OTC sales, cross-DAO delegation (one DAO voting inside another — live on mainnet), external Governor DAOs, Safe multisig.
Tool catalog
173 tools in 19 groups. Full per-tool reference with required env vars: docs/TOOLS.md.
A default session loads the core profile — 46 tools, ~94 KB of tools/list. That is orientation (dexe_context, dexe_write_context, dexe_guide, dexe_doctor), the one-call composites (dexe_dao_create, dexe_proposal_create, dexe_proposal_vote_and_execute, the four dexe_otc_* composites with the token-sale reads dexe_read_token_sale_position / dexe_read_token_sales), signing (dexe_tx_send, dexe_tx_approval_status, WalletConnect, the key vote builders), the IPFS upload trio plus dexe_ipfs_fetch, dexe_dao_info / dexe_dao_registry_lookup / dexe_dao_predict_addresses, dexe_proposal_state / _list / _catalog, dexe_read_treasury / _settings, and the zero-config reporting reads (dexe_dao_report, dexe_graph_query, dexe_graph_schema, DAO list/members/stats, token holders, delegation map). Which profile to run, and what each costs: docs/PROFILES.md.
Changed in v0.31.0: the ~30 single-purpose dexe_proposal_build_* builders are no longer loaded by default — dexe_proposal_create covers every on-chain catalog type from proposalType + params, and dexe_proposal_catalog still enumerates them. Set DEXE_TOOLSETS=core,proposals to restore the pre-0.31 default exactly. Add profiles (proposals, read, vote, agents, governor, dev) or DEXE_TOOLSETS=full for everything — see docs/PROFILES.md. Note before reaching for full: it registers all 173, and some hosts (VS Code / GitHub Copilot) cap a chat request at 128 enabled tools per request and reject the session above that; the server prints a startup note when you cross it. Call dexe_context first in a session: it returns the active chain, env readiness, which profiles are off and what each unlocks, and DAOs/proposals recorded in prior sessions. Since v0.36.0 the signer, the agent keyring and the Pinata / WalletConnect / Safe posture are dexe_write_context.
New in v0.32.0: agents, a seventh profile for running a multi-persona fleet — dexe_agents_list (who is in the keyring, and their balances), dexe_agents_fund (top them up, preview-then-confirm, inside the enforced caps), and dexe_agents_ledger (who did what, and what it cost). Set DEXE_TOOLSETS=core,agents and restart; add vote (core,agents,vote) when the scenario needs the raw delegation and validator builders. dexe_agents_list / dexe_agents_fund also remain in vote, so an existing core,vote session keeps exactly the surface it had. Details and the safety model: docs/AGENTS.md.
The Tools column counts the whole group, not what a default session loads — most groups sit behind a profile. docs/TOOLS.md names the profile at the top of every section.
Group | Tools | Summary |
Dev tooling | 4 | Hardhat lifecycle for the DeXe-Protocol workspace: |
Contract introspection | 10 | List contracts, fetch ABIs, look up selectors, read NatSpec and source, decode calldata and proposal payloads. |
DAO reads | 34 |
|
IPFS | 9 | Pinata uploads for files, avatars, and DAO/proposal metadata; metadata updates; JPEG avatar generation; gateway-fallback fetch; local CID computation. |
DAO deploy | 4 |
|
Proposal catalog and primitives | 5 |
|
External proposal wrappers | 20 | Named builders: token transfer/distribution/sale, treasury withdraw, validators, experts, staking tiers, blacklist, profile changes, voting settings, and more. |
Internal validator wrappers | 4 | Validator-chamber proposals: balances, settings, monthly withdraw, off-chain internal. |
Off-chain wrappers and auth | 9 | DeXe backend integration: SIWE login, off-chain proposal creation and voting. |
Vote, stake, delegate, execute, claim builders | 26 | Direct EOA writes on |
Composite signing flows | 13 |
|
Merkle utility | 2 |
|
OTC composites | 4 | Open a multi-tier sale, read a buyer's position ( |
Safe multisig | 2 | Queue transactions in the Safe Transaction Service instead of broadcasting. docs/SAFE.md |
Simulator | 3 |
|
Multi-DAO inbox + forecast | 2 | Pending items across N DAOs ( |
External Governor DAOs | 18 |
|
WalletConnect | 3 |
|
Diagnostics | 1 |
|
Environment variables
No variable is required to start the server; tools that need a missing one fail with a message naming what to set. Full matrix: docs/ENVIRONMENT.md.
Variable | Used for | Notes |
| all on-chain tools | Per-chain JSON-RPC endpoints. Without any, a public BSC RPC is used (rate-limited). |
| chain selection | Default |
| hardening | Set |
| IPFS uploads | Required to broadcast a DAO/proposal creation (metadata pinning). Previews and |
| IPFS reads | Dedicated gateway (Pinata, Filebase, self-hosted). Without one, public gateways (ipfs.io, dweb.link) are used. |
| IPFS reads | Gateway key for restricted Pinata dedicated gateways. |
| hardening | Set |
| WalletConnect signing | A shared default ships; set your own project ID for production use. |
| signing |
|
| unattended mode | Hot-key signing, read only in |
| tool gating | Comma list of profiles; default |
| subgraph reads | The Graph endpoints; defaults target the decentralized network. |
| subgraph reads | Only when the URL doesn't embed the key. |
| off-chain proposals | DeXe backend, e.g. |
| persistence | Overrides the session-state file ( |
| dev toolset | Existing DeXe-Protocol checkout; disables auto-clone. |
| hardening | Set |
| CI | Set |
Documentation
docs/USE_CASES.md — verified use-case catalog: what to say to your agent, what happens, on-chain evidence.
docs/PLAYBOOK.md — the AI playbook: intent → exact call, per-type params, error → remedy. Also served as the MCP resource
dexe://playbook.docs/AGENT-COUNCIL.md —
npx dexe-mcp council: AI agents vote on a DAO's proposals from the decoded on-chain actions, with the proposer's text fenced as untrusted.docs/TOOLS.md — all 173 tools, grouped, with one-line descriptions, the toolset profile each section needs, and required env vars. Also served as the MCP resource
dexe://tools.docs/REPORTING.md —
dexe_dao_report: the one-call DAO report, its sections, thesincediff, and running it on a schedule.docs/USAGE.md — worked examples with copy-pasteable JSON.
docs/ENVIRONMENT.md — full env-var reference and common pitfalls.
docs/INSTALL.md — install instructions per MCP client.
docs/PROFILES.md — which
DEXE_TOOLSETSprofile to run, what each costs intools/list, and the host tool-count cap.docs/SETUP.md / docs/DOCTOR.md — setup wizard and diagnostic reference.
docs/AGENTS.md — multi-persona agent teams: the safety model for a hot-key fleet, the
agentstoolset, funding guards, the run sequence that works on-chain, and the attribution ledger.docs/SKILLS.md — the Claude Code skills shipped with the package.
docs/GRAPH.md — subgraph entity reference for
dexe_graph_query(pools / interactions / validators). Also served as the MCP resourcedexe://graph-schema.docs/GOVERNOR.md — the external OZ/Bravo Governor surface.
docs/SIGNING.md — signer modes (WalletConnect, encrypted keystore, read-only, unattended), the approval page, and the threat model.
docs/WALLETCONNECT.md — phone-approved signing without a hot key.
docs/OTC.md — multi-tier OTC sale flows for owners and buyers.
docs/PROFILE.md — DAO profile and avatar pipeline.
docs/SIMULATOR.md — preflight simulation with revert decoding.
docs/INBOX.md — cross-DAO inbox and proposal forecast.
docs/MIGRATION.md — per-version upgrade notes.
docs/REMOTE.md — the read-only edition
dexe-mcp-read: stdio setup, and hosting it over HTTP (serve-http, Docker) for remote clients.
Swarm test harness
tests/swarm/ is a multi-agent harness that exercises the tool surface against real BSC-testnet DAOs: 69 JSON scenarios covering delegation chains, the validator chamber, build-only checks for every proposal type, OTC flows, and full broadcast lifecycles. The orchestrator resolves agent wallets and runs each step through an inline ethers dispatcher or the dexe-mcp stdio bridge.
npm run swarm:preflight # per-wallet readiness table
npm run swarm:fund -- --confirm # top up agent wallets from the funder
npm run swarm:run # full sweep
npm run swarm:run -- --scenarios=S00-reset --dry-runSetup runbook: tests/swarm/README.md · scenario schema: tests/swarm/scenarios/_schema.md · agent prompts: tests/swarm/prompts/.
Contributing
git clone https://github.com/edward-arinin-web-dev/dexe-mcp.git
cd dexe-mcp
npm install
npm run build
npm test
npm run dev # watch modeIssues, PRs, and proposal-type requests: GitHub issues.
Security
See SECURITY.md for the threat model, policy, and how to report a vulnerability. In short:
Release tags are GPG-signed;
release.ymlrunsgit verify-tagbefore publishing. Verify locally withgit verify-tag <tag>(e.g.v0.19.0) after importing the maintainer key.npm releases publish with
--provenance; verify withnpm audit signatures.CI installs strictly from the committed lockfile and fails on drift.
CodeQL, OSSF Scorecard, and Dependency Review run on PRs and on a schedule.
License
MIT. See LICENSE.
Available Tools
48 toolsdexe_contextSession contextARead-onlyIdempotent
Read-only. Session orientation — configured chains and the default, env readiness (RPC/IPFS/subgraph/backend), which toolsets are on or hidden and what the hidden ones unlock, and the DAOs/proposals recorded in this install's local state. Pass user to add that wallet's deposited power in the newest recorded DAO. Not needed once the DAO and chain are known. Persisted DAOs/proposals are WINDOWED; the *Total fields carry real counts.
Inputs: user, daoLimit, proposalLimit.
dexe_dao_createDeploy a new DAOADestructive
Broadcasts when a signer is configured. Deploys a new DeXe DAO in ONE call. SIMPLE mode (recommended): pass symbol + totalSupply and the tool synthesizes a coherent, frontend-equivalent config (LINEAR power, treasury as an implicit remainder, a quorum that passes on realistic turnout). ADVANCED mode: pass a full params struct. Returns a preview of the resolved config + a safety proof and broadcasts only with confirm: true. Runs the frontend's governance coherence guards over ALL FIVE settings slots (default / internal / validators / distribution / tokenSale) — one un-passable slot bricks that whole proposal class forever — plus a calldata round-trip self-check and a pre-sign eth_call: a provable revert is refused with a classified cause + fix BEFORE any gas is spent, while an RPC outage only downgrades to a warning. Mainnet (56) always needs confirm: true (real BNB); validate on testnet (97) first. deployer defaults to the signer. Unsure of the journey or params? Call dexe_guide (flow:'create_dao').
Inputs: daoName (required), dryRun, params, symbol, +23 more.
dexe_dao_generate_avatarGenerate a deterministic placeholder avatar for a DAOA
Writes to a remote service. Renders a real JPEG of the DAO's initials over a hash-coloured gradient and pins it, returning {avatarCID, avatarFileName, avatarUrl}. Deterministic.
Inputs: daoName (required), size. Returns: size, pinnedAt, avatarCID, avatarUrl, +1 more
dexe_dao_infoDAO overview — helpers, NFT contracts, validator countARead-onlyIdempotent
Read-only. One multicall on a GovPool: helper addresses, NFT contract addresses, description URL, and live validator count.
Inputs: govPool (required), chainId. Returns: govPool, helpers, nftContracts, descriptionURL, +1 more
dexe_dao_predict_addressesPredict addresses for a future DAO deploymentARead-onlyIdempotent
Read-only. Calls PoolFactory.predictGovAddresses(deployer, poolName) — the six CREATE2-predicted contract addresses for a DAO before it is deployed.
Inputs: deployer (required), poolName (required), chainId. Returns: govPool, govToken, expertNft, govTokenSale, +2 more
dexe_dao_registry_lookupCheck whether an address is a DeXe GovPoolARead-onlyIdempotent
Read-only. Calls PoolRegistry.isGovPool(address) — true when the address is a registered DeXe DAO GovPool.
Inputs: address, chainId, govPool. Returns: address, chainId, isGovPool, poolRegistry
dexe_dao_reportFull DAO report — one call, every section, with a since-diffARead-onlyIdempotent
Read-only. The whole picture of one DAO in one call — every section named by sections (default all), plus everything with a DEADLINE: open votes, executable proposals and, with user, unvoted proposals and claimable rewards. Pass since (ISO timestamp, Unix seconds, block:<n>, or last) for ONLY what changed; each run stores a snapshot so the next since diff has a baseline. Sections degrade independently; unavailable ones are NAMED in unavailable[] with the reason.
Inputs: govPool (required), user, since, chainId, +4 more. Returns: since, chainId, changes, govPool, +9 more
dexe_doctorDiagnose env setupARead-onlyIdempotent
Read-only. Diagnoses env setup — the cause and the fix of an env-related failure: presence + reachability checks (RPC, Pinata, IPFS gateway DNS, subgraph, backend) as pass/warn/fail with remediation hints. Warnings are advisories — a healthy zero-config install always has some. probePin is the one write: one tiny IPFS pin.
Inputs: probePin, _placeholder.
dexe_get_configResolved server configARead-onlyIdempotent
Read-only, local. The resolved read config: chain set and default chain, subgraph coverage per chain, the backend API and the IPFS read gateways.
Inputs: _placeholder.
dexe_graph_queryFree-form GraphQL query against a DeXe subgraphARead-onlyIdempotent
Read-only. GraphQL against a DeXe subgraph: 'pools' (DAOs, proposals, voters, delegations, experts, sales), 'interactions' (per-user tx feed), 'validators'. Bound every list with first: (max 1000), page with skip:; oversized responses are rejected. Entity and field names must match the subgraph schema exactly — root fields are not entity names (DaoPool -> daoPools), and a wrong name errors with where to look it up. chainId picks the endpoint (pools: 56, validators: 56, interactions: 56; default 56); the reply echoes indexedChainId, never another chain's rows.
Inputs: query (required), subgraph (required), chainId, variables.
dexe_graph_schemaIntrospect a DeXe subgraph schemaARead-onlyIdempotent
Read-only. Live introspection of a DeXe subgraph schema — the valid names for a GraphQL query, e.g. after "Type 'X' has no field 'Y'". Omit entity for the root query field map (each entity -> the field name to query it by); pass entity for that type's fields, '_filter' for valid where: keys, '_orderBy' for valid orderBy: values. An unknown name returns ranked candidates. chainId picks the endpoint (pools: 56, validators: 56, interactions: 56; default 56); the reply echoes indexedChainId, never another chain's rows.
Inputs: subgraph (required), entity, chainId.
dexe_guideFlow plans and pitfallsARead-onlyIdempotent
Read-only, local. The plan for a multi-step or unfamiliar DeXe request — 'create a DAO', 'launch a token with distribution/OTC/staking', 'open a sale', 'pass this proposal': the ordered steps (which tools, in what order, with what params), the questions to ask the user with per-parameter risk notes, and the known pitfalls for that journey. Reference topics answer data questions the same way (flow:"read_dao_data" covers the whole read surface). No args or a free-text intent returns the menu; flow returns the full plan.
Inputs: flow, intent, chainId.
dexe_ipfs_fetchFetch content by CID (dedicated gateway, optional fallback)ARead-onlyIdempotent
Read-only. Fetches IPFS content by CID through the server's gateway chain: its dedicated gateway first when it has one, then the configured or public fallbacks.
Inputs: cid (required), timeoutMs. Returns: cid, json, gateway, attempts, +3 more
dexe_ipfs_upload_avatarUpload a DAO avatar (one-shot: pins + returns avatarCID/avatarFileName/avatarUrl)A
Writes to a remote service. Pins an image, returning {avatarCID, avatarFileName, avatarUrl}. PREFER filePath; never pass base64 through the conversation. Magic-byte validated (JPEG/PNG/WebP/GIF only — SVG/HTML render broken on app.dexe.io); renamed .jpeg; CID v1 base32.
Inputs: base64, fileName, filePath, contentType. Returns: size, pinnedAt, avatarCID, avatarUrl, +2 more
dexe_ipfs_upload_fileUpload raw bytes (avatar, attachment, etc.) to IPFS (Pinata)A
Writes to a remote service. Pins a file to IPFS; PREFER filePath over base64. Returns CID v1 (base32) + filename. Images are magic-byte gated to rasters and renamed .jpeg unless normalizeImageExt: false.
Inputs: base64, fileName, filePath, contentType, +1 more. Returns: cid, size, cidV0, fileName, +1 more
dexe_ipfs_upload_proposal_metadataUpload proposal metadata JSON to IPFS (Pinata)A
Writes to a remote service. Pins {proposalName, proposalDescription} to IPFS via Pinata; returns the CID for descriptionURL in GovPool.createProposal.
Inputs: title (required), extra, description. Returns: cid, size, pinnedAt, descriptionURL
dexe_otc_buyer_buyBuy from an OTC tierADestructive
Broadcasts when a signer is configured. Preflights balance + allowance, adds an ERC20 approve when needed, then builds TokenSaleProposal.buy(tierId, paymentToken, amount, proof). Native path (0x000...000) skips approve and sets value; whitelistUsers generates the proof.
Inputs: amount (required), tierId (required), tokenToBuyWith (required), tokenSaleProposal (required), +7 more.
dexe_otc_buyer_claim_allClaim all OTC purchasesADestructive
Broadcasts when a signer is configured. Reads getUserViews(user, tierIds) and sends claim for tiers with claimableAmount > 0. Tiers whose only balance is the VESTED leg are reported under vestingBlocked and NOT sent — vestingWithdraw is refused by the pool's firewall (upstream defect F15); includeVesting: true tries anyway.
Inputs: tierIds (required), tokenSaleProposal (required), user, dryRun, +3 more.
dexe_otc_buyer_statusToken sale position for a wallet (old name)ARead-onlyIdempotent
Read-only. Deprecated alias of dexe_read_token_sale_position (renamed in 0.36.0); same input and output.
Inputs: user (required), tierIds (required), tokenSaleProposal (required), chainId, +1 more.
dexe_otc_dao_open_saleOpen an OTC token saleADestructive
Broadcasts when a signer is configured. Proposes a multi-tier token sale on an OTC DAO: builds the createTiers envelope (deduped approves, auto-merkle, auto-addToWhitelist, merkle lists pinned to IPFS so buyers can regenerate proofs), then runs the proposal_create flow (approve, deposit, IPFS metadata, createProposalAndVote). DAOs from dexe_dao_create (v0.19+) already wire TokenSaleProposal as an executor; older ones need a new_proposal_type proposal first.
Inputs: tiers (required), govPool (required), user, dryRun, +11 more.
dexe_otc_list_sales_for_daoList a DAO's token sale tiers (old name)ARead-onlyIdempotent
Read-only. Deprecated alias of dexe_read_token_sales (renamed in 0.36.0); same input and output.
Inputs: govPool (required), chainId, tokenSaleProposal.
dexe_proposal_catalogList every proposal type DeXe supportsBRead-only
Read-only, local. Every proposal type DeXe supports (external, internal validator, off-chain) with target, IPFS-metadata need, gating and builder tool.
Inputs: category, implementedOnly. Returns: total, types, externalMetadataShape, internalMetadataShape
dexe_proposal_createCreate a proposalADestructive
Broadcasts when a signer is configured. Creates ANY governance proposal in ONE call: runs approve→deposit→createProposalAndVote and uploads correct IPFS metadata (category/isMeta/changes). Without a signer it returns ordered TxPayloads + a WalletConnect QR.\nPass proposalType — the enum lists every wired type — with its inputs in params:\n• 'custom': your own actionsOnFor [{executor,value,data}]. 'modify_dao_profile' reads the top-level newDaoName/newDaoDescription/newWebsiteUrl/newSocialLinks/newAvatarPath fields, not params.\n• External: token_transfer {token,recipient,amount,isNative?} · withdraw_treasury {receiver,token?,amount?,nftAddress?,nftIds?} · change_voting_settings {govSettings?,settings[],settingsIds?} · add_expert/remove_expert {expertNftContract,scope,nominatedUser,uri?} · token_sale_whitelist {tokenSaleProposal,requests[]} · token_sale_recover {tokenSaleProposal,tierIds[]} · manage_validators {govValidators,changes[]} · validators_allocation {credits[]} · delegate_to_expert/revoke_from_expert {expert,amount,nftIds?} · change_math_model {newVotePower} · blacklist {erc20Gov,addAddresses?,removeAddresses?} · apply_to_dao {token,receiver,amount} · new_proposal_type/enable_staking {govSettings?,settings,executors,newSettingId} · custom_abi {target,signature,method,args?} · token_distribution · token_sale · create_staking_tier · reward_multiplier.\n• Internal (validators-only): change_validator_balances {changes[]} · change_validator_settings {duration,executionDelay,quorum} · monthly_withdraw {withdrawals[],destination} · offchain_internal_proposal {}.\nOff-chain backend types are rejected with the flow to use instead. Full recipes with examples: dexe://playbook, or dexe_proposal_catalog.
Inputs: title (required), govPool (required), user, dryRun, +21 more.
dexe_proposal_listList proposals on a GovPoolBRead-onlyIdempotent
Read-only. Calls GovPool.getProposals(offset, limit) and adds quorum progress per proposal. Quorum is per-side — either For or Against clearing the target reaches it; requiredQuorum is an ABSOLUTE vote weight, not a percentage.
Inputs: govPool (required), limit, offset, chainId. Returns: limit, total, offset, govPool, +4 more
dexe_proposal_stateLive proposal state + required quorumARead-onlyIdempotent
Read-only. Reads getProposalState, getProposalRequiredQuorum and the proposal's votes in one multicall. requiredQuorum is an ABSOLUTE vote weight, not a percentage; quorum is per-side — either For or Against clearing it reaches quorum.
Inputs: govPool (required), proposalId (required), chainId. Returns: state, govPool, votesFor, proposalId, +10 more
dexe_proposal_vote_and_executeVote on and execute a proposalADestructive
Broadcasts when a signer is configured. The ONE call for 'vote on / pass / execute proposal N': checks proposal state, AUTO-DEPOSITS wallet tokens when voting power is short (approve UserKeeper → deposit → vote, the frontend's bundled shape), and with autoExecute executes once the vote passes. Without a signer it returns ordered TxPayloads + a WalletConnect QR. Unsure of the lifecycle (validator round, locked tokens)? Call dexe_guide (flow:'vote_execute') first.
Inputs: govPool (required), proposalId (required), user, dryRun, +9 more.
dexe_read_dao_listDiscover and list DAOs (subgraph)ARead-onlyIdempotent
Read-only. Paginated DAO discovery via the pools subgraph; name search is case-insensitive, ordered by voter count descending. Pass chainId (chains with a pools endpoint here: 56; default 56); the reply echoes indexedChainId, never another chain's rows. No endpoint for a chain = an error that names the on-chain reads to use instead.
Inputs: limit, query, offset, chainId.
dexe_read_dao_membersList DAO members with voting power (subgraph)ARead-onlyIdempotent
Read-only. Paginated member list for a DAO — voting power, delegation counts, rewards, expert status. Pass chainId (chains with a pools endpoint here: 56; default 56); the reply echoes indexedChainId, never another chain's rows. No endpoint for a chain = an error that names the on-chain reads to use instead.
Inputs: govPool (required), limit, offset, chainId.
dexe_read_dao_statsDAO TVL + activity stats time seriesARead-onlyIdempotent
Read-only. Time series of DAO stats (tvl_usd, member counts, proposal counts, delegations) from the DeXe tracker. period is a human duration like '24 hours', '7 days', '1 months'. Backend-only — mainnets.
Inputs: govPool (required), period, chainId, maxPoints. Returns: data, period, points, chainId, +3 more
dexe_read_delegation_mapDelegation relationships — outgoing or incoming (subgraph)ARead-onlyIdempotent
Read-only. Delegation pairs from the pools subgraph: direction='outgoing' = who a user delegated to, 'incoming' = who delegated to them. Pass chainId (chains with a pools endpoint here: 56; default 56); the reply echoes indexedChainId, never another chain's rows. No endpoint for a chain = an error that names the on-chain reads to use instead.
Inputs: addresses (required), limit, offset, chainId, +1 more.
dexe_read_settingsDefault + internal proposal settings for a DAOBRead-onlyIdempotent
Read-only. Reads GovSettings.getDefaultSettings() and getInternalSettings() for the DAO at govPool — quorum, duration, executionDelay, minVotesForCreating/Voting.
Inputs: govPool (required), chainId. Returns: govPool, settings, defaultSettings, internalSettings
dexe_read_token_holdersTop holders of an ERC20 token (with balances)ARead-onlyIdempotent
Read-only. Holders + raw balances for any ERC20 from the DeXe backend, balance desc, one page per call (see pageToken). Mainnets only (1, 56).
Inputs: token (required), chainId, pageSize, pageToken. Returns: count, token, chainId, holders, +2 more
dexe_read_token_sale_positionToken sale position for a walletARead-onlyIdempotent
Read-only. Tier params + user state across N tiers: purchasable status, claimable amount, vesting withdrawable, lockup ETA, totalSold, merkle root. whitelists adds the user's proof, making canParticipate accurate for gated tiers.
Inputs: user (required), tierIds (required), tokenSaleProposal (required), chainId, +1 more.
dexe_read_token_salesList a DAO's token sale tiersARead-onlyIdempotent
Read-only. Reads latestTierId() then getTierViews(0, latestTierId) on the DAO's TokenSaleProposal: tiers with totalSold and status (upcoming/active/ended/off) computed from the current block timestamp and the tier's on-chain isOff flag. On-chain only — any chain with an RPC; the reply echoes the resolved chainId. tokenSaleProposal defaults to the address this install's local state records for the DAO; otherwise it is required.
Inputs: govPool (required), chainId, tokenSaleProposal.
dexe_read_treasuryTreasury or wallet balances (native + ERC20, USD)ARead-onlyIdempotent
Read-only. Treasury / wallet balances for any address; pass a GovPool address for a DAO treasury. Auto-discovers EVERY token via the DeXe backend with USD prices and a total. Falls back to an on-chain read (chain 97, explicit tokens, or a backend failure) — no token discovery there, and it reports degraded: true.
Inputs: holder, tokens, chainId, govPool. Returns: holder, native, source, tokens, +4 more
dexe_tx_approval_statusKeystore approval statusARead-only
Read-only. Status + landed tx hashes of a keystore approval (awaiting_approval). Cannot approve; only the owner can, on the page.
Inputs: approvalId (required), waitMs.
dexe_tx_sendSign and broadcast a transactionADestructive
Broadcasts when a signer is configured. Sends the TxPayload fields from any dexe_*build* tool and waits for confirmation. Pass chainId when several chains are configured, plus the payload's own chainId as payloadChainId — a mismatch REFUSES the send. Calldata with a privileged GovUserKeeper accounting selector is refused (hard block, no override).
Inputs: to, data, value, chainId, +5 more.
dexe_tx_statusTransaction statusARead-only
Read-only. Receipt/status for a submitted tx hash (pending vs not_found). A broadcast timeout is not a failure — the tx may still confirm; re-check here.
Inputs: txHash (required), chainId.
dexe_vote_build_depositStake tokens/NFTs into a DAO to gain voting powerARead-only
Builds calldata; does not broadcast. GovPool.deposit(amount, nftIds) — stakes into the DAO to gain voting power. Payable: native-coin DAOs pass value; ERC20 DAOs pass value=0 and need the GovUserKeeper approve first.
Inputs: amount (required), govPool (required), value, nftIds, +1 more. Returns: payload, warnings, advisories
dexe_vote_build_erc20_approveBuild ERC20.approve(spender, amount) calldataARead-only
Builds calldata; does not broadcast. ERC20.approve(spender, amount). Run it before dexe_vote_build_deposit when staking an ERC20: approve the DAO's GovUserKeeper (dexe_dao_info), never the GovPool. Native-coin staking needs no approve — pass value on deposit instead.
Inputs: token (required), amount (required), spender (required), chainId, +1 more. Returns: payload, warnings, advisories
dexe_vote_build_executeExecute a passed proposalARead-only
Builds calldata; does not broadcast. GovPool.execute(proposalId); scope:'internal' + govValidators builds GovValidators.executeInternalProposal(proposalId) (anyone may send once Succeeded). When an action calls GovSettings.addSettings the response carries an advisory naming the chains where the proposal passes the vote and then reverts here — read it before signing.
Inputs: govPool (required), proposalId (required), scope, voter, +2 more. Returns: payload, warnings, advisories
dexe_vote_build_voteVote on an external proposalARead-only
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).
Inputs: amount (required), govPool (required), isVoteFor (required), proposalId (required), +3 more. Returns: payload, warnings, advisories
dexe_vote_build_withdrawUnstake tokens/NFTs from a DAOARead-only
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.
Inputs: amount (required), govPool (required), receiver (required), nftIds, +1 more. Returns: payload, warnings, advisories
dexe_vote_user_powerUser staking + delegation power across VoteTypesARead-onlyIdempotent
Read-only. Reads tokenBalance and nftBalance on GovUserKeeper for every VoteType (Personal/Micropool/Delegated/Treasury) in one multicall. tokenBalance includes the un-deposited wallet balance; deposited power = tokenBalance - tokenOwned.
Inputs: user (required), govPool (required), chainId. Returns: user, power, govPool, userKeeper
dexe_wc_connectConnect a wallet by QRA
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.
Inputs: chainId.
dexe_wc_disconnectDisconnect the walletA
Writes to a remote service. Tears down the active WalletConnect session; safe when not connected.
Inputs: _placeholder.
dexe_wc_statusWalletConnect session stateARead-only
Read-only. WalletConnect config plus live session state (connected?, account, chain, topic, peer wallet, last error). It dispatches transactions in DEXE_SIGNER_MODE=walletconnect (the default).
Inputs: chainId.
dexe_write_contextSigner and write postureARead-only
Read-only. Write posture for this session — the signer mode + address (WalletConnect, keystore, hot key or none), the agent KEYRING (signerKey, address, gas, 24h broadcasts per persona), Pinata / WalletConnect / Safe readiness, the signer's deposited power in the newest recorded DAO, and a write journey a prior session left unfinished. Chains, env readiness and recorded DAOs are dexe_context.
Inputs: includeAgentBalances, includeDepositedPower.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 48 tools
Descriptions are extremely detailed and carry strong cues ('read-only', 'builds calldata', 'broadcasts'), but the surface contains real overlap: two explicit deprecated aliases (dexe_otc_list_sales_for_dao → dexe_read_token_sales, dexe_otc_buyer_status → dexe_read_token_sale_position) do exactly what another tool does, and three avatar/image tools (dexe_dao_generate_avatar, dexe_ipfs_upload_avatar, dexe_ipfs_upload_file) are easy to confuse. There is also a deliberate high-level vs low-level layering (dexe_proposal_vote_and_execute vs dexe_vote_build_vote + dexe_tx_send) that an agent must reason about before choosing.
Everything is snake_case with a uniform dexe_ prefix and clear domain groupings (dao_, proposal_, vote_, ipfs_, tx_, wc_, otc_, read_), which keeps it readable. However the verb layer is inconsistent: read_ vs get_ vs bare domain nouns (dexe_dao_info, dexe_get_config, dexe_read_settings, dexe_proposal_list) and odd forms like dexe_otc_buyer_status sit alongside build_/create_ verbs, so there is no single predictable verb_noun pattern.
48 tools is well past the heavy threshold for a single server, and a meaningful chunk of that count is duplication rather than capability (two deprecated aliases, multiple overlapping avatar/IPFS tools, parallel high-level and build-level vote/execute paths). The full DAO + token-sale + graph + wallet + diagnostics surface justifies breadth, but it should have been consolidated into fewer, cleaner entry points.
Coverage is genuinely broad: DAO discovery/creation/inspection, members, delegations, treasury and holder reads, full proposal lifecycle (catalog, create, list, state, vote, execute), staking deposit/withdraw/approve, IPFS read/write, OTC token sales end-to-end, validator internals, tx send/status, WalletConnect and diagnostics. Minor gaps remain, such as a first-class user-to-user delegation build tool (only delegation reads and expert-delegation proposals exist) and per-proposal metadata retrieval outside the generic graph query.
Maintenance
Related MCP Connectors
Signed BNB Chain reads (balances, tokens, NFTs, prices, TapeOut names) with verifiable receipts
Official Aave MCP for V3 and V4 markets, positions, governance, and transaction preparation.
Live onchain governance, vesting, oracle and Safe authority checks. Free samples over MCP.
Warden MCP lets AI agents find tokens, quote swaps and trade onchain on Base, BNB Chain, Robinhood Chain, Arc and Solana, within limits you set. Market tools need no credential: list_chains, search_tokens, trending_tokens, price_history, quote_swap and swap_status. Search by name, ticker or contract address, read USD price candles, and price a swap before committing to it, including cross-chain swaps. Wallet tools act for the wallet whose owner connected the agent, by OAuth sign-in or a wk_ key. agent_permissions shows what the agent may do and its daily limits. prepare_swap builds a trade and hands the owner a review link to sign. With request_session the owner turns on hands-free trading in one tap, and execute_swap then trades within the limits they set. swap_status tracks gasless and cross-chain trades. get_wallet shows holdings on every chain. Gasless trading is available on Base, BNB Chain and Robinhood Chain. Built by Warden Protocol, the team behind Warden Token Terminal.
Related MCP Servers
- FlicenseNot gradedqualityCmaintenanceA comprehensive MCP server for interacting with the BNB Chain ecosystem, including BSC EVM operations, BNB Greenfield decentralized storage, and the Sperax Protocol. It enables users to manage wallets, execute token transactions, and handle storage buckets using natural language.31 npm35-
- AlicenseNot gradedqualityNot gradedmaintenanceA comprehensive Model Context Protocol server that enables AI agents to interact with BNB Chain, opBNB, and other EVM networks through natural language. It provides tools for DeFi trading, DEX swaps, smart contract deployment, token operations, security analysis, and market data across multiple blockchain networks.31 npm-
- AlicenseCqualityCmaintenanceWeb3 MCP proxy server for AI agents: EVM execution, DeFi swaps, bridges, advanced orders, market data, wallet management, and confirmation-gated writes.10078 npm1MIT
- AlicenseNot gradedqualityBmaintenanceEnables agents to propose policy-gated treasury payments and swaps, check pending human approvals, read transaction receipts, and locally verify their integrity through MCP tools.MIT