Skip to main content
Glama
Sign In
dexe-mcp

dexe-mcp

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

Free-form GraphQL query against a DeXe subgraph

dexe_graph_query
Read-onlyIdempotent

Query DeXe subgraph data through read-only GraphQL to retrieve DAOs, proposals, voters, delegations, interactions, and validators, using first/skip pagination and exact schema field names.

Instructions

Read-only. GraphQL against a DeXe subgraph: 'pools' (DAOs, proposals, voters, delegations, experts, sales), 'interactions' (per-user tx feed), 'validators'. Bound every list with first: (max 1000), page with skip:; oversized responses are rejected. Entity and field names must match the subgraph schema exactly — root fields are not entity names (DaoPool -> daoPools), and a wrong name errors with where to look it up. chainId picks the endpoint (pools: 56, validators: 56, interactions: 56; default 56); the reply echoes indexedChainId, never another chain's rows.

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": {
      "subgraph": "<subgraph>",
      "query": "<query>"
    },
    "name": "dexe_graph_query"
  }
}

Input Schema

NameRequiredDescriptionDefault
queryYesGraphQL query document (read-only)
chainIdNoChain to read from: 56 mainnet, 97 testnet. Needs an RPC for it. Default: the configured chain.
subgraphYesWhich DeXe subgraph to query
variablesNoGraphQL variables referenced by the query

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.37.1

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare read-only/idempotent, and the description adds genuinely new behavior: a hard 1000-item cap with rejection of oversized responses, endpoint selection via `chainId`, and the guarantee that the reply echoes `indexedChainId` and never returns another chain's rows. It also discloses the failure mode for mismatched root/entity names, which is the most common way this tool breaks.

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?

Front-loads "Read-only." then builds from subgraph list to paging rules to naming pitfalls to chain behavior in a single dense but scannable block. The chainId enumeration repeats 56 three times plus a default, which wastes space without adding information.

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 does the heavy lifting on limits, paging, naming errors, and the chain-echo guarantee, which is enough for an agent to construct a valid query. It stops short of describing auth/prerequisites or any guidance on result shape or field selection, which for an open-ended query tool is a modest gap.

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; the description adds value by documenting the `chainId` default (56) and how chain choice maps to the endpoint. It leaves `variables` and the exact `first`/`skip` placement inside the query document to inference, and the repeated "56" for all three subgraphs is redundant rather than informative.

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+resource ("GraphQL against a DeXe subgraph") and immediately enumerates the three selectable subgraphs and the entity families inside each, so an agent knows exactly what surface it reaches. It also implicitly distinguishes itself from the schema-lookup sibling by noting that wrong field names error with "where to look it up".

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 concrete operational rules: bound every list with `first:` (max 1000), page with `skip:`, and expect rejection for oversized responses. It does not explicitly say "call dexe_graph_schema first to discover field names" or when to prefer a higher-level sibling like dexe_read_dao_list, so the alternatives routing is suggested rather than stated.

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