Related Servers

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.