Skip to main content
Glama
Sign In
dexe-mcp

dexe-mcp

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

Introspect a DeXe subgraph schema

dexe_graph_schema
Read-onlyIdempotent

Introspect DeXe subgraph schemas to resolve valid GraphQL query fields, where filters, and orderBy values, returning ranked candidates when names are unknown.

Instructions

Read-only. Live introspection of a DeXe subgraph schema — the valid names for a GraphQL query, e.g. after "Type 'X' has no field 'Y'". Omit entity for the root query field map (each entity -> the field name to query it by); pass entity for that type's fields, '_filter' for valid where: keys, '_orderBy' for valid orderBy: values. An unknown name returns ranked candidates. 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>"
    },
    "name": "dexe_graph_schema"
  }
}

Input Schema

NameRequiredDescriptionDefault
entityNoType name to expand, e.g. 'Proposal', 'VoterInPool', 'DaoPool_filter', 'Proposal_orderBy'. Omit for the root query field map.
chainIdNoChain to read from: 56 mainnet, 97 testnet. Needs an RPC for it. Default: the configured chain.
subgraphYesWhich DeXe subgraph to introspect

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.37.1

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description earns credit for going further: an unknown name returns ranked candidates rather than failing silently, and the reply echoes `indexedChainId` and 'never another chain's rows', which is a real data-integrity guarantee an agent could not infer otherwise. The opening 'Read-only' merely restates readOnlyHint=true.

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-loaded and single-paragraph with no filler sentences; every clause carries operational content. The chainId parenthetical repeating 56 three times is the one wasteful stretch and slightly muddies the default-endpoint point.

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?

No output schema exists, and the description compensates by describing all three return shapes (root entity->field map, per-type field lists, ranked candidate suggestions on failure) plus the `indexedChainId` echo. Complete enough for a 3-parameter introspection tool; only the exact shape of a ranked-candidate reply is left unstated.

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?

With 100% schema coverage the baseline is 3, and the description adds genuine meaning: the omit-vs-pass semantics of `entity`, the `<Entity>_filter`/`<Entity>_orderBy` naming conventions, and the fact that unknown values yield ranked candidates. It adds little on `chainId` beyond the schema (the 'pools: 56, validators: 56, interactions: 56; default 56' list is repetitive and omits the 97 testnet the schema documents).

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: live introspection of a DeXe subgraph schema returning 'the valid names for a GraphQL query'. That framing cleanly separates it from dexe_graph_query (which returns data) without needing to name the sibling, and the 'dexe_graph_schema' name plus title reinforce it.

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 triggering scenario ('after "Type 'X' has no field 'Y'"') and precise mode-selection rules: omit `entity` for the root query field map, pass `entity` for that type's fields, `<Entity>_filter` for `where:` keys, `<Entity>_orderBy` for `orderBy:` values. It stops short of an explicit when-not-to-use or a named alternative tool, so it lands just under the top band.

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