Subgraph Registry MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_subgraphsA | Search and filter the classified subgraph registry (15,500+ subgraphs). Filter by domain (defi, nfts, dao, gaming, identity, infrastructure, social, analytics), network (mainnet, arbitrum-one, base, matic, bsc, optimism, avalanche), protocol_type (dex, lending, bridge, staking, options, perpetuals, nft-marketplace, yield-aggregator, governance, name-service), canonical entity type (liquidity_pool, trade, token, position, vault, loan, collateral, liquidation, nft_collection, nft_item, nft_sale, proposal, delegate, domain_name, account, transaction, daily_snapshot, hourly_snapshot), or free-text keyword. Returns subgraphs ranked by reliability score with query URLs. To query data: POST GraphQL to https://gateway.thegraph.com/api/[api-key]/subgraphs/id/[subgraph-id] (get API key from https://thegraph.com/studio/apikeys/). |
| recommend_subgraphA | Given a natural-language goal like 'find DEX trades on Arbitrum' or 'get lending liquidation data', returns the best matching subgraphs with reliability scores and query URLs. Automatically infers domain and protocol type from the goal. Each result includes a query_url — replace [api-key] with your Graph API key to query live data. |
| get_subgraph_detailA | Get full classification detail for a specific subgraph by its subgraph ID or IPFS hash. Returns domain, protocol type, canonical entities, all entity names with field counts, reliability score, signal data, query URL, and step-by-step query instructions. |
| list_registry_statsA | Get an overview of the subgraph registry: total count, available domains, networks, and protocol types with counts. Use this to understand what data is available before searching. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool has a clearly distinct purpose: get_subgraph_detail retrieves detailed metadata for a specific subgraph, list_registry_stats provides high-level registry overview, recommend_subgraph offers goal-based recommendations, and search_subgraphs enables filtered discovery. There is no overlap in functionality, making tool selection straightforward for an agent.
All tool names follow a consistent verb_noun pattern (get_subgraph_detail, list_registry_stats, recommend_subgraph, search_subgraphs) with clear, descriptive verbs that align with their actions. The naming is uniform and predictable across the set.
With 4 tools, the server is well-scoped for its purpose of subgraph registry interaction. The tools cover key workflows: exploration (list_registry_stats), discovery (search_subgraphs, recommend_subgraph), and detailed access (get_subgraph_detail), without being overly sparse or bloated.
The toolset provides comprehensive coverage for querying and discovering subgraphs, including overview, search, recommendation, and detail retrieval. A minor gap is the lack of tools for managing or updating registry entries (e.g., add/remove subgraphs), but this is reasonable for a read-only registry interface focused on data access.