Skip to main content
Glama
Sign In
dexe-mcp

dexe-mcp

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

Delegation relationships — outgoing or incoming (subgraph)

dexe_read_delegation_map
Read-onlyIdempotent

Read delegation pairs from the pools subgraph for given wallet addresses, returning outgoing delegates or incoming delegators by chain.

Instructions

Read-only. Delegation pairs from the pools subgraph: direction='outgoing' = who a user delegated to, 'incoming' = who delegated to them. 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": {
      "addresses": "<addresses>"
    },
    "name": "dexe_read_delegation_map"
  }
}

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.
addressesYesVoter WALLET addresses (plain 0x…40-hex). Composite VoterInPool ids ('govPool-voter' or 80-hex 'voter+pool' concatenations) are also accepted — the voter part is extracted automatically.
directionNooutgoing = who I delegated to; incoming = who delegated to meoutgoing

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.37.1

TDQS

A3.9/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the prefix 'Read-only' adds nothing. The genuinely additive parts are the disclosure that the reply echoes `indexedChainId` so rows can never come from another chain, and that an unsupported chain yields an error naming on-chain alternatives rather than silent empty results.

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 read-only marker and the direction semantics that drive usage, with each sentence carrying distinct information. The clause 'chains with a pools endpoint here: 56' is terse to the point of being cryptic and slightly undercuts the otherwise clean structure.

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?

Covers what matters for a 5-parameter subgraph read with no output schema: chain support, the echo field that validates the response, and failure behavior. Pagination and address formats are delegated entirely to the schema, which is reasonable given full coverage, leaving only the default-chain ambiguity unaddressed.

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 limit, offset, addresses and direction are already documented, and the description largely restates the direction enum. The one real addition is narrowing usable chains to those with a pools endpoint (56), which usefully sharpens the schema's looser '56 mainnet, 97 testnet' note — though the resulting tension with the schema's stated default is left unresolved.

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 ('Read delegation pairs from the pools subgraph') plus the scope qualifier that matters most: direction selects outgoing vs incoming edges. No sibling in the catalog reads delegation data, so an agent can route to this tool from the name plus description alone.

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?

Explains the selection criterion between the two modes (who a user delegated to vs who delegated to them) and constrains chain selection, which is effectively a precondition for calling it. It stops short of naming an alternative tool for out-of-scope cases, only saying an error will point to on-chain reads instead.

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