Skip to main content
Glama

Deploy a new DAO

dexe_dao_create
Destructive

Deploys a new DeXe DAO in one call from a token symbol and supply or a full params struct, returning a config preview and governance safety checks before any BNB is spent.

Instructions

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').

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": {
      "daoName": "<daoName>"
    },
    "name": "dexe_dao_create"
  }
}

Input Schema

NameRequiredDescriptionDefault
dryRunNoPreview: no broadcast, no IPFS pin, no Pinata key needed. CIDs are right but unpinned — do NOT broadcast this calldata.
paramsNoADVANCED mode: the full deployGovPool params struct. Prefer SIMPLE mode. Field-by-field schema: dexe_dao_build_deploy (needs DEXE_TOOLSETS=core,dev).
symbolNoSIMPLE mode: gov token symbol (e.g. 'GENA'). Required when `params` is omitted.
chainIdNoTarget chain id. Defaults to the MCP's default chain. Use 97 (BSC testnet) to validate; 56 = BSC mainnet (real funds).
confirmNoTrue to actually broadcast; without it SIMPLE mode and any mainnet deploy return a review-only preview. Pass it on the FIRST call when the user has already approved the deploy.
daoNameYesDAO name (also the deployGovPool pool name)
deployerNotx.origin that sends the deploy (needed for address prediction). Defaults to the signer address.
avatarCIDNoIPFS CID of an already-pinned JPEG avatar (dexe_ipfs_upload_avatar)
documentsNoExternal documents shown on the DAO profile, e.g. [{ name: "Whitepaper", url: "https://..." }]
signerKeyNoKeyring signer: omit = primary key; 'agent<n>' or address = a DEXE_AGENT_PK_* key.
voteModelNoSIMPLE mode: vote-power model. LINEAR = 1 token = 1 vote (default). POLYNOMIAL = meritocratic curve.LINEAR
avatarPathNoLocal avatar image path (JPEG/PNG/WebP/GIF ≤10 MB) — server validates + pins it. Preferred over avatarCID.
recipientsNoSIMPLE mode: split the votable share across wallets (default: deployer only). Percents are of TOTAL supply and must sum to 100 − treasuryPercent.
websiteUrlNoDAO website URL shown on its profile.
flowContextNoGuided-flow position from dexe_guide's step templates. Adds flowProgress + next to the result and persists it.
poolFactoryNoPoolFactory override; defaults to ContractsRegistry lookup
socialLinksNo[[network, url], ...]
totalSupplyNoSIMPLE mode: total token supply in WHOLE tokens (e.g. '1000000'). Required when `params` is omitted.
confirmRiskyNoProceed despite a governance-safety refusal. Read the returned `risks` to the user FIRST — such a config cannot be repaired after deploy, because repairing it needs a proposal passed under it. Ignored when DEXE_TREASURY_GUARD=block.
quorumPercentNoSIMPLE mode: quorum, percent 0-100. Omit and the tool picks (default 51). Must be >=50 and clearable by at most 80% turnout — a quorum equal to the votable share freezes the DAO forever.
avatarFileNameNoFile name stored alongside avatarCID.avatar.jpeg
daoDescriptionNoDAO description (markdown; uploaded to IPFS as slate)
minVotesTokensNoSIMPLE mode: min tokens to vote AND create proposals, WHOLE tokens. Default '1'. Must be ≤ the largest holder's allocation.1
durationSecondsNoSIMPLE mode: voting duration. Default 86400 (1 day).
earlyCompletionNoSIMPLE mode: end voting as soon as the quorum is reached. Default true.
treasuryPercentNoSIMPLE mode: treasury share, percent 0-100 (implicit remainder; it cannot vote). Omit and the tool picks one that leaves a real voting margin (default 30).
executionDelaySecondsNoSIMPLE mode: delay before execution. Default 0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.37.1

TDQS

A3.7/5.0
Behavior2/5

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

The description is unusually rich about failure behavior: coherence guards over all five settings slots, calldata round-trip self-check, pre-sign eth_call with classified revert causes, RPC outage downgrading to a warning, and irreversible bricking risk. However, the annotations declare destructiveHint=true and the description never plainly frames this as an irreversible, gas-spending on-chain write outside the mainnet parenthetical, so the destructive classification is only indirectly acknowledged.

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

Conciseness3/5

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

The middle sentences are long run-ons cramming guards, eth_call semantics, and chain policy into one paragraph, and the leading 'Broadcasts when a signer is configured' sentence earns no place. The critical information (SIMPLE vs ADVANCED, confirm, testnet-first) does appear early, which limits the damage.

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 27-parameter deploy tool with no output schema, it covers mode selection, safety preconditions, and references the guide and dexe_dao_build_deploy for the unexplored struct. It names some return elements (preview, safety proof, risks, flowProgress/next) but not the full response shape.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema by explaining the SIMPLE/ADVANCED split, that treasuryPercent is an implicit non-voting remainder, and the quorum clearability constraint. It does not explain the already-documented nested params struct, but that is farmed out to dexe_dao_build_deploy.

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

Purpose4/5

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

The description states a specific verb and resource ('Deploys a new DeXe DAO in ONE call') and explicitly separates SIMPLE from ADVANCED mode, which an agent needs to pick a call shape. The opening sentence, 'Broadcasts when a signer is configured,' is an unrelated fragment that muddies the very first thing the agent reads.

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?

It gives concrete routing rules: SIMPLE is recommended, ADVANCED requires a full params struct, validate on testnet (97) before mainnet (56), dryRun for previews, confirmRisky only after reading risks to the user, and dexe_guide (flow:'create_dao') when unsure. Both the when and the when-not cases are covered.

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