Several of the tools are there purely so the model lands on an active deployment before it queries — keyword search, then a volume check, then the schema — because the same protocol has many stale copies indexed. The instructions resource makes that sequence mandatory, so ask your client to load it; without it a model tends to query the first result it sees.
A server over The Graph Network. It finds subgraphs by keyword, checks which deployment is actually being used, fetches its GraphQL schema, and runs your query against it.
- Subgraphs found by keyword in their display names, ordered by signal (search_subgraphs_by_keyword)
- Recent query volume for a set of deployments, which is how you tell a live subgraph from an abandoned one (get_deployment_30day_query_counts)
- The GraphQL schema for a deployment, whichever identifier you hold — subgraph ID, deployment ID or IPFS hash (get_schema_by_subgraph_id, get_schema_by_deployment_id, get_schema_by_ipfs_hash)
- Your GraphQL query executed against a deployment named any of those same three ways (execute_query_by_subgraph_id, execute_query_by_deployment_id, execute_query_by_ipfs_hash)
- The busiest deployments indexing a given contract address on a chain, ordered by query fees (get_top_subgraph_deployments)
- A server-instructions resource that spells out the selection workflow, plus prompts for most of the tools
- Prometheus metrics for tool calls and gateway requests when it runs as an HTTP service
A Gateway API key for The Graph Network. You can point at the hosted service through a remote bridge, or build the Rust binary and run it yourself; the request timeout is configurable on a local instance.
One command plus a key — npx mcp-remote --header Authorization:${AUTH_HEADER} https://subgraphs.mcp.thegraph.com/sse, then supply credentials