dexe-mcp

Create a proposal

dexe_proposal_create

Destructive

Creates any DeXe governance proposal in one call, handling approval, deposit, IPFS metadata, and voting; without a signer, it returns ordered transactions and a WalletConnect QR to sign.

Instructions

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.

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>",
      "title": "<title>"
    },
    "name": "dexe_proposal_create"
  }
}

Input Schema

Name	Required	Description
`user`	No	User address. Required when no signer is loaded.
`title`	Yes	Proposal title
`dryRun`	No	Preview: no broadcast, no IPFS pin, no Pinata key needed. The metadata CID is right but unpinned — do NOT broadcast this calldata.
`params`	No	Type-specific builder inputs for the chosen proposalType (recipes: tool description / dexe://playbook).
`chainId`	No	Target chain (56 mainnet, 97 testnet); needs an RPC for it. Default: the MCP's default chain.
`govPool`	Yes	DAO GovPool address (dexe_dao_registry_lookup).
`category`	No	Proposal category (included in IPFS metadata).
`signerKey`	No	Keyring signer: omit = primary key; 'agent<n>' or address = a DEXE_AGENT_PK_* key.
`newDaoName`	No	modify_dao_profile: the DAO's new display name.
`voteAmount`	No	Auto-vote amount: raw wei (digits only) or human units with a decimal point ('12.5'). Default: all available power.
`voteNftIds`	No	Your governance NFT token ids, decimal; [] for ERC20-only DAOs.
`description`	No	Proposal description (markdown supported)
`flowContext`	No	Guided-flow position from dexe_guide's step templates. Adds flowProgress + next to the result and persists it.
`actionsOnFor`	No	Actions run when the proposal passes. Required for proposalType:'custom'.
`confirmRisky`	No	Required when the built proposal carries a DANGER governance-safety advisory. Without it the flow refuses BEFORE any transaction.
`newAvatarCID`	No	modify_dao_profile: IPFS CID of an already-pinned avatar.
`proposalType`	No	What kind of proposal to create — required in practice. 'custom' means you supply actionsOnFor. Unsure? Call dexe_proposal_catalog.
`newAvatarPath`	No	Local avatar image path (JPEG/PNG/WebP/GIF, max 10 MB) — the server validates and pins it for you.
`newWebsiteUrl`	No	modify_dao_profile: the DAO's new website URL.
`allowDuplicate`	No	The create is SKIPPED when a live proposal already carries the same IPFS metadata URL (a resumed run). True mints a second identical proposal on purpose.
`newSocialLinks`	No	modify_dao_profile: [[network, url], ...].
`newAvatarBase64`	No	Base64 image bytes — only when the image isn't a local file.
`newAvatarFileName`	No	modify_dao_profile: file name stored with newAvatarCID.
`newDaoDescription`	No	modify_dao_profile: the DAO's new description (markdown).
`proposalMetadataExtra`	No	Extra fields merged into IPFS metadata.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.37.1Nov 11, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Beyond the readOnlyHint=false / destructiveHint=true annotations, it discloses that a transaction is broadcast only when a signer is configured and that without one the call degrades into a payload-plus-QR handoff. The stated approve→deposit→create sequence is meaningful behavioral context for a destructive multi-transaction call. It does not say whether a created proposal can be cancelled, what permissions are needed, or how the success result is shaped.

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?

Front-loaded with the one-call pipeline and the no-signer fallback, then organized as a scannable bulleted type list. It is dense and long, and a few trailing bullets are thin name-only entries, but almost every line carries routing information an agent would otherwise have to infer.

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 25-parameter, nested-object, destructive tool with no output schema, it covers the operating modes, the enum-to-input mapping, and where to get full recipes. The main remaining gap is the return shape on success (proposal id, tx hash, metadata URL) and any reversibility caveat, which an agent must learn by other means.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema coverage the baseline is 3, and the description earns more by mapping inputs to enum values — e.g. 'custom' requires actionsOnFor and 'modify_dao_profile' reads top-level newDaoName/newDaoDescription/newWebsiteUrl/newSocialLinks/newAvatarPath rather than `params`. Several listed types (token_distribution, token_sale, create_staking_tier, reward_multiplier, offchain_*) are named without their inputs, so the mapping is useful but incomplete.

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 ('Creates ANY governance proposal in ONE call') and spells out the internal pipeline (approve→deposit→createProposalAndVote) plus IPFS metadata upload, which no sibling does. It also distinguishes the two operating modes: broadcast with a signer versus returning ordered TxPayloads and a WalletConnect QR without one.

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?

Routes the agent well: pick a proposalType from the enum, put its inputs in `params`, and defer to dexe_proposal_catalog / dexe://playbook when unsure. It also notes that off-chain backend types are rejected with the flow to use instead. It stops short of an explicit 'do not use this for X, use Y' against siblings such as dexe_ipfs_upload_proposal_metadata or dexe_proposal_vote_and_execute.

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

Deploy Server