Skip to main content
Glama
Sign In
dexe-mcp

dexe-mcp

by edward-arinin-web-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

List DAO members with voting power (subgraph)

dexe_read_dao_members
Read-onlyIdempotent

Fetch a paginated, read-only list of DAO members with voting power, delegation counts, rewards, and expert status; specify govPool, chainId, limit, and offset.

Instructions

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.

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

Input Schema

NameRequiredDescriptionDefault
limitNoMax rows per page.
offsetNoRows to skip (pagination).
chainIdNoChain to read from: 56 mainnet, 97 testnet. Needs an RPC for it. Default: the configured chain.
govPoolYesGovPool address (lowercased for subgraph)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.37.1

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the bar is lower, and the description does add value: pagination, the reply echoing indexedChainId so no cross-chain rows leak, and the failure mode for unsupported chains. It says nothing about result limits beyond pagination, sorting, or what an empty DAO returns, so it is good but not rich.

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?

Short and front-loaded: "Read-only" then the resource and payload, then the chain caveat. The chain sentence is densely packed with three separate facts (supported chain, echo behavior, error fallback) which slightly hurts scanability but every clause earns its place.

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?

With no output schema, the description carries the burden of describing returns and does so by listing the member fields and the indexedChainId echo. The chainId default discrepancy against the schema is the main completeness gap for a tool an agent must call correctly on the first try.

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 coverage is 100%, so the schema already documents all four parameters and a baseline of 3 applies. The description adds useful meaning about the chainId echo, but it also conflicts with the schema by claiming "default 56" while the schema says the default is the configured chain and allows 97 as testnet — an ambiguity the agent must resolve from the schema alone.

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 names a specific verb+resource ("Paginated member list for a DAO") and enumerates the returned fields (voting power, delegation counts, rewards, expert status). It does not explicitly distinguish itself from likely siblings such as dexe_vote_user_power or dexe_read_delegation_map, so it stops short of 5.

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?

It gives real routing guidance: pass chainId for chains with a pools subgraph endpoint, and if no endpoint exists for a chain you get an error that names the on-chain reads to use instead — an implicit when-not alternative. There is no explicit statement of when to prefer this over the per-user voting-power or delegation-map siblings.

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

Deploy Server

Other Tools