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: Axon Research MCP Server
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.
Inputs: days.
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.
Inputs: tokenId (required).
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.
Inputs: no named parameters.
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.
Inputs: limit, window.
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.
Inputs: address (required), window.
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.
Inputs: vault (required), days, includeSeries.
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.
Inputs: vault (required), days.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored 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.
Read-only Hyperliquid vault search, risk, drawdown, rankings, TVL, alerts, and comparisons.
DeFi TVL, stablecoin supply, perp funding, top coins and prediction-market data as agent tools.
Web search, point-in-time crypto market data, verified strategy track records and 160+ agent tools.
