Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@erc4626-mcp which vaults can you see, and how do their returns compare?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that reasons over ERC-4626 vault subgraphs and the Cope Market copy graph, reading live data from The Graph.
Point it at any subgraph following the standardized ERC-4626 schema and it will describe, chart and rank the vaults there — across chains and across protocols, with no per-protocol code.
npx @cope-market/erc4626-mcpIn a client that speaks MCP over stdio:
{
"mcpServers": {
"erc4626": {
"command": "npx",
"args": ["-y", "@cope-market/erc4626-mcp"]
}
}
}No API key, no account, nothing to configure. The shipped default reads three live deployments across two chains, which is enough to try every tool.
Related MCP server: Graph AAVE MCP
Tool | Answers |
| What vaults are visible, with assets, decimals and share price |
| One vault's size, holders, and whether it is growing |
| Return, annualised rate, maximum drawdown, daily share price |
| Every visible vault ranked by return |
| Traders ranked by realised P&L over a window |
| One trader's results, and separately how their copiers did |
| One position's copy tree, and whether copying it paid |
The trader tools appear only when a Cope Market subgraph is configured.
run_query toolThe Graph's own brief rules out "simply querying one Subgraph". An MCP server that exposes a raw GraphQL passthrough is that, relabelled as tooling: it moves the querying to the model and computes nothing itself. So every tool here computes something no single query returns — a drawdown is the whole series walked, a windowed ranking is individual positions aggregated, a copier outcome is positions grouped by the author of the position they copied rather than by their own author.
A test asserts no tool name ever looks like a query passthrough.
ERC4626_MCP_CONFIG=/path/to/config.json npx @cope-market/erc4626-mcp{
"vaultSubgraphs": [
{
"key": "my-vaults",
"label": "My vaults",
"network": "mainnet",
"url": "https://api.studio.thegraph.com/query/.../my-erc4626/v0.1.0"
}
],
"copeSubgraph": null
}One subgraph can index many vaults; the tools enumerate across all of them. A malformed config file fails at startup rather than falling back to the default — falling back would answer about our vaults while you believed it was answering about yours.
Read-only by construction. There is no signer in the process, no write path, and nothing that
takes a private key. Every tool is annotated readOnlyHint: true and a test enforces it. An agent
pointed at this can be wrong; it cannot be dangerous.
Unknown is never rounded to zero. A vault with one snapshot has no return — reporting zero would read as "flat", which is a claim about performance rather than an admission of ignorance. Those vaults rank last in a comparison rather than mid-table. The same holds for an address with no history and for an empty window.
Balances never pass through a float. An eighteen-decimal balance is past what a double holds
exactly, so amounts are formatted digit by digit and sums are BigInt. Share prices are ratios
near one and do go through a double, which is safe and is stated where it happens.
Annualising is refused below a day. Compounding a rounding difference over a few hundred periods is how a vault that moved 0.01% in an hour gets advertised at 8000% APY.
Every figure carries its block. A vault's assets move without emitting anything, so a subgraph figure is as of the last indexed event and not the chain head. Handed a bare number, a model will state it as current.
npm install
npm run check # format, typecheck, test, build
npm run build && npx tsx scripts/smoke.ts # every tool against the live subgraphsscripts/smoke.ts spawns the built server and speaks the protocol to it over stdio, which is the
only check that the thing a user installs actually works.
MIT.
Compares every vault across every configured subgraph over one period and ranks them by return, with drawdown and size alongside. Works across chains and across protocols because all of them are indexed by the same standardized ERC-4626 schema — no per-protocol code is involved. Use this to answer which vault has done best.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Period, in days |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly=true, destructive=false, openWorld=true), but the description adds real behavioral context: it aggregates across chains and protocols via a shared ERC-4626 schema, so no per-protocol branches occur, and results carry drawdown and size alongside return. It omits result-size/pagination expectations for a tool that scans every vault.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core compare-and-rank action before the rationale. The 'no per-protocol code is involved' clause slightly re-states the preceding standardization point but remains informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must convey returns, and it does — ranking with return, drawdown, and size — which is adequate for a one-parameter, read-only tool. It leaves out how the ranked result set is shaped or limited, a minor gap given the 'every vault' scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'days' parameter is fully documented in the schema, so the baseline is 3. The description adds only that the period applies to the whole cross-vault comparison ('over one period'), with no defaults, bounds, or format nuance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb (compares/ranks) and resource (ERC-4626 vaults), plus the scope (every vault, every configured subgraph) and the ranking criterion (return, with drawdown and size). This is functionally distinct from list_vaults and vault_overview, though no sibling is named explicitly to sharpen the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly states the use case — 'Use this to answer which vault has done best' — which tells the agent when this tool applies. It stops short of naming a competing sibling or stating when NOT to use it (e.g., for a single vault, use vault_overview).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
For one position, shows what it did, what every copy of it did, and the total outcome for the copiers. Answers whether following this specific call made anyone money, which is a different question from whether the call itself was right.
| Name | Required | Description | Default |
|---|---|---|---|
| tokenId | Yes | The position's ERC-721 token id, as a decimal number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds that the output aggregates copier outcomes — useful scope context — but says nothing about performance, latency, or completeness of the copy set.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences, front-loaded with what the tool shows before the interpretive framing. No filler or restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only analytics tool with no output schema, the description sketches the return contents (position behavior, copy behavior, total copier outcome). Enough for correct invocation, though a hint about the shape or size of the lineage result would close the remaining gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single tokenId parameter is fully documented as a decimal ERC-721 id in the schema. The description adds no additional parameter meaning, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: for one position it shows what the position did, what its copies did, and the aggregate copier outcome. That is distinct from the vault-oriented siblings (list_vaults, vault_overview, trader_record), though the description never names a sibling to sharpen the contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It frames the question the tool answers ('whether following this specific call made anyone money, which is a different question from whether the call itself was right'), which implies when it is useful. But there is no explicit when-to-use vs. the six sibling tools and no stated exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enumerates every vault across the configured subgraphs, with its asset, decimals, current share price and how far each subgraph has indexed. Start here: the addresses and source keys it returns are what the other tools take as arguments. Reports a subgraph that is unreachable rather than omitting it.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld and non-destructive, so safety is covered. The description adds real behavioral context beyond that: it discloses the multi-subgraph fan-out, that results are per-subgraph index progress, and that unreachable subgraphs are surfaced rather than silently dropped — a partial-failure behavior an agent needs to plan for.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each earning its place: what it returns, why to call it first, and the failure-handling guarantee. The routing instruction is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description carries the return-shape burden, and it does: asset, decimals, share price, per-subgraph index progress, plus unreachable-subgraph reporting. For a zero-parameter discovery tool this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so there is nothing for the description to disambiguate; the 4 baseline applies. The description correctly does not invent parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Enumerates every vault across the configured subgraphs') and immediately scopes what each entry carries. It is clearly distinguishable from siblings like vault_overview or compare_vaults, which operate on vaults already known from this list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs 'Start here' and explains why: the addresses and source keys returned are the arguments the other tools consume. This is a concrete when-to-use rule that routes the agent to this tool before the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ranks traders by realised P&L over a window, with win rate and how many of their positions were liquidated. Aggregated from individual closed positions, which is the only way to get a windowed figure: the subgraph stores lifetime totals. Credit goes to whoever opened a position, not whoever held it at the end.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| window | No | 30d |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only and non-destructive behavior, so the description adds value by disclosing data provenance (aggregated from closed positions, subgraph lifetime-total limitation) and an attribution rule (credit to opener, not holder). That is real behavioral context beyond the structured fields, though it omits anything about result freshness or ordering ties.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences that front-load the ranking and then explain the aggregation rationale; little is wasted. Slightly more than strictly needed for a tool this simple, but each clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully names the returned fields (win rate, liquidation count) and explains the windowing model. The main gap is parameter semantics for an analytics tool with two undocumented inputs, but otherwise an agent has enough to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden, yet it only alludes to 'a window' without explaining the enum values (7d/30d/90d/all), and it never mentions the limit parameter or how the ranking is truncated. It adds conceptual color but not usable parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (ranks), resource (traders) and metric (realised P&L over a window), plus the returned dimensions. It clearly differs from siblings like trader_record, which covers a single trader rather than a ranked list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The provenance note ('the subgraph stores lifetime totals', so aggregation is the only way to get a windowed figure) implies why you would pick this over a raw subgraph query, but it never names an alternative tool or states when-not to use it. Usage is inferable rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A trader's lifetime results and, separately, what happened to everyone who copied them. The second figure is the one that matters for deciding whether to follow somebody: a trader can be profitable while the people copying them are not.
| Name | Required | Description | Default |
|---|---|---|---|
| window | No | Window used for the copier outcomes | all |
| address | Yes | The trader's wallet address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a safe, open-world read (readOnlyHint=true, destructiveHint=false), so the bar is lower. The description goes further by disclosing the internal shape of the payload — two distinct result sets — and the interpretive caveat that a profitable trader can have unprofitable copiers, which is genuine behavioral insight not present in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with what the record contains before the interpretive second sentence. The second sentence is partly editorial ("the one that matters") rather than operational, but it is short and conveys a real interpretation caveat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the burden of conveying return content, and it does sketch the two result groups. It stops short of naming concrete fields or handling cases like an unknown address or a trader with no copiers, leaving minor gaps for a two-parameter read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters (address, window enum with default) are already fully documented, making 3 the baseline. The description adds only a mild clarification that results are "lifetime" while the windowed figure applies to copier outcomes, which loosely aligns with the schema but does not resolve the ambiguity of how window interacts with the trader's own results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource precisely: a single trader's lifetime results plus the separate outcomes of their copiers. That two-part structure is specific enough to distinguish this from list-oriented siblings like top_traders, but it never explicitly contrasts itself with any named sibling, so an agent must infer the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"The second figure is the one that matters for deciding whether to follow somebody" gives an implied use case, so the agent can infer when this record is relevant. However, there is no explicit when-not guidance and no mention of alternatives (e.g. copy_lineage for network structure or top_traders for ranking).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return over a period, annualised rate, maximum drawdown and the daily share price series. None of these are stored: they are computed by walking the snapshots. Use this to answer whether a vault has made money and how bumpy the ride was.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Period, in days | |
| vault | Yes | Vault address, symbol or name | |
| includeSeries | No | Include the day-by-day share price series as well as the summary |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely non-obvious behavioral context beyond that: the metrics "are computed by walking the snapshots" rather than stored, which explains cost/latency characteristics. It stops short of disclosure on pagination or the exact snapshot source.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences front-loaded with the returned metrics, followed by an implementation note and a usage cue. No filler, and the most decision-relevant content (what it returns) leads.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only computed-metrics tool with no output schema, the description names the return values (period return, annualised rate, max drawdown, series) and the computation mechanism, which is enough to call it correctly. Minor gaps around snapshot data source and response shape are acceptable given the annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so days, vault, and includeSeries are all documented in the schema itself. The description references the period and the daily series (mapping to days and includeSeries) but adds no format or semantic detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (return) and enumerates the computed metrics: over a period, annualised rate, maximum drawdown, daily share price series. This clearly identifies a per-vault historical performance tool. It doesn't explicitly differentiate from siblings like vault_overview, but the historical/return-focused scope is evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use this to answer whether a vault has made money and how bumpy the ride was" gives implied usage context tied to the metrics. However, it names no alternative and offers no when-not guidance against siblings such as vault_overview or compare_vaults, leaving tool selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current size, share price, holders and the flows over a window for a single vault. Accepts an address, a symbol such as mwUSDC, or a name. Returns deposits and withdrawals over the window and the net of the two, which is the figure that says whether a vault is growing.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Window for the flow figures, in days | |
| vault | Yes | Vault address, symbol or name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. With no output schema in play, the description usefully discloses the return content (deposits, withdrawals, and their net) and interprets the net as the growth signal. Rate limits and error behavior remain undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the output inventory front-loaded and the acceptance criteria following. The clause 'which is the figure that says whether a vault is growing' is mildly editorial but earns its place by interpreting the net flow value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description carries the burden of explaining returns — and it does, naming the deposit, withdrawal and net flow figures. Missing details are minor: the default 30-day window and the units/format of share price and size.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description restates the accepted vault formats and adds a concrete example (mwUSDC), but the address/symbol/name enumeration and the window concept are already documented in the schema, leaving only marginal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete subject (a single ERC-4626 vault) and enumerates the fields returned — current size, share price, holders, and windowed flows. The phrase 'for a single vault' implicitly separates it from list_vaults and compare_vaults, though no sibling is named directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the scope qualifier 'for a single vault'; there is no explicit when-to-use guidance and no alternative tool is named. An agent must infer the routing decision against list_vaults, vault_history, and compare_vaults from the sibling list alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0compare_vaultscopy_lineagelist_vaultstop_traderstrader_recordvault_historyvault_overviewScored across 7 tools
Tools have distinct purposes: list_vaults enumerates, vault_overview gives current stats, vault_history provides historical performance, and compare_vaults ranks across vaults. Minor potential overlap exists between vault_overview and vault_history, but descriptions clarify their different time scopes. Trader tools (top_traders, trader_record, copy_lineage) are also well differentiated by granularity.
Names mix verb_noun patterns (list_vaults, compare_vaults) with noun_noun patterns (vault_overview, vault_history, trader_record, copy_lineage) and an adjective_noun pattern (top_traders). All use snake_case and remain readable, but there is no single predictable convention. The inconsistency is noticeable but not confusing.
Seven tools are well-scoped for a read-only analytics server covering ERC-4626 vaults and copy-trading metrics. Each tool has a clear role, and the count is comfortably within the ideal 3–15 range. No tool feels redundant or missing for the apparent scope.
The surface covers vault enumeration, detailed current/historical analytics, cross-vault comparison, trader rankings, individual trader records, and position-level copy lineage. Core workflows are complete, but minor gaps exist such as no direct vault fee or strategy detail, though these can likely be worked around. Overall, the read-only analytics domain is well served.
Search 700+ DeFi vaults, compare risk scores, analyze protocols. No API key needed.
Crypto yield data for AI agents: lending, savings, staking, borrowing & stablecoin rates. 18 tools.
Read-only Hyperliquid vault search, risk, drawdown, rankings, TVL, alerts, and comparisons.
Pay-per-call (x402/USDC-Base) web + crypto data tools for AI agents: audit, extract, crypto, DeFi.
