dexe-mcp

Open an OTC token sale

dexe_otc_dao_open_sale

Destructive

Proposes a multi-tier OTC token sale on a DeXe DAO: builds the createTiers envelope with merkle whitelists pinned to IPFS, then runs the proposal flow to approve, deposit, and create the vote.

Instructions

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.

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>",
      "tiers": "<tiers>"
    },
    "name": "dexe_otc_dao_open_sale"
  }
}

Input Schema

Name	Required	Description	Default
`user`	No	Acting address; defaults to the configured signer.
`tiers`	Yes	Tier specs for `createTiers`, in order; at least one.
`dryRun`	No	Preview: no broadcast, no IPFS pin. CIDs are right but unpinned — do NOT broadcast.
`chainId`	No	Target chain id. Defaults to the MCP's default chain.
`govPool`	Yes	GovPool address
`buildOnly`	No	Return only the envelope (actions + metadata + merkle roots); skips IPFS and DAO reads.
`signerKey`	No	Keyring signer: omit = primary key; 'agent<n>' or address = a DEXE_AGENT_PK_* key.
`voteAmount`	No	Vote size: whole tokens ('12.5') or raw wei. Omit to vote with all available power.
`voteNftIds`	No	Your governance NFT token ids, decimal; [] for ERC20-only DAOs.
`flowContext`	No	Guided-flow position from dexe_guide's step templates. Adds flowProgress + next to the result and persists it.
`latestTierId`	No	Current `latestTierId()` on the sale; new tiers start after it.	0
`proposalName`	No	Proposal title in the DAO UI.	Open OTC Token Sale
`tokenSaleProposal`	No	TokenSaleProposal helper address. Omit for a DAO this install deployed (recorded at deploy); otherwise dexe_dao_predict_addresses or the deploy receipt.
`proposalDescription`	No	Proposal body; Markdown supported.
`acknowledgeVestingBlocked`	No	Refused by default: opt into vestingPercentage > 0; the vested leg is stranded (F15).

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.37.1Nov 11, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations declare a non-read-only, destructive operation, and the description adds meaningful context beyond them: it broadcasts only when a signer is configured, dedupes approvals, auto-builds merkle roots, pins lists to IPFS, and submits votes in the same run. It does not explicitly warn about irreversibility or cost, but the side-effect chain is well disclosed.

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?

Three dense sentences, front-loaded with the primary action and followed by the mechanics and then the version prerequisite. The opening clause about broadcasting when a signer is configured is slightly awkward as a lead but carries information; no filler sentences.

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 15-parameter, nested-object, destructive tool with no output schema, the description explains the end-to-end pipeline and the deployment-version caveat that would otherwise block a correct call. Remaining gaps are minor since parameter-level details and preview modes are documented in the schema.

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 15 parameters are already documented, which sets the baseline at 3. The description adds only modest cross-parameter meaning — that merkle/whitelist handling and approve/deposit/metadata steps are automatic, and that older DAOs need an explicit TokenSaleProposal — but says nothing about dryRun, buildOnly, voteAmount, or flowContext beyond what the schema states.

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 (proposes a multi-tier token sale on an OTC DAO) and then names the exact on-chain artifacts it produces (`createTiers` envelope plus the `proposal_create` flow). An agent can distinguish it from dexe_proposal_create and dexe_otc_buyer_buy without opening any 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 a concrete prerequisite: DAOs deployed via `dexe_dao_create` v0.19+ already wire TokenSaleProposal as an executor, while older DAOs need a `new_proposal_type` proposal first. That is real when-to-use routing, though it stops short of explicitly naming the sibling to call in the older-DAO case or when to prefer a plain proposal.

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

Deploy Server