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., "@graph-lido-mcp What's the current Lido staking APR?"
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.
MCP server for querying Lido liquid staking protocol data via The Graph's decentralized network.
16 tools, 5 guided prompts. Staking stats, APR history, withdrawals, node operators, governance, and more.
Get a free API key from Subgraph Studio
Add to your MCP client config:
{
"mcpServers": {
"graph-lido": {
"command": "npx",
"args": ["-y", "graph-lido-mcp"],
"env": {
"GRAPH_API_KEY": "your-api-key"
}
}
}
}Works with Claude Desktop, Cursor, Cline, and any MCP-compatible client.
Related MCP server: everstake-mcp
get_lido_stats - Total pooled ETH, shares, unique holders, fee structure, staking status, withdrawal queue status
get_staking_apr - APR history from oracle reports with fee breakdown and MEV fees
get_recent_submissions - Recent stETH deposits with amounts, shares received, referrals
get_recent_transfers - stETH token transfers with optional address and minimum value filters
get_holder_shares - Look up any address's current stETH share balance and computed ETH value
get_withdrawal_requests - Pending withdrawal requests (unstaking)
get_withdrawal_claims - Completed withdrawals (ETH received)
get_withdrawals_finalized - Finalization batches (ETH locked, shares burned)
get_shares_burns - Share burn events from withdrawal processing
get_node_operators - Professional validator operators: names, staking limits, stopped validators
get_oracle_reports - Beacon chain balance and validator count per epoch
get_governance_votes - Lido DAO Aragon votes with proposal metadata
get_vote_details - Individual voter records for a specific proposal
get_easytrack_motions - Lightweight governance motions for routine operations
get_lido_schema - Introspect the full GraphQL schema
query_lido_subgraph - Run any raw GraphQL query
Prompt | Description |
staking_overview | Total ETH staked, current APR trend, recent deposits, holder count |
withdrawal_monitor | Queue health, pending requests, recent claims, net flow direction |
governance_digest | Recent DAO votes, EasyTrack motions, contentious decisions |
node_operator_analysis | Operator set diversity, stopped validators, staking limits |
whale_tracker | Large deposits, big transfers, whale withdrawal patterns |
"What is the current Lido staking APR?"
"How much total ETH is staked with Lido?"
"Show me whale deposits over 100 ETH"
"Who are Lido's node operators?"
"What's the withdrawal queue status?"
"Show me recent DAO governance votes"
"Look up the stETH balance for 0x..."
"What EasyTrack motions were enacted this month?"The Lido subgraph uses _collection suffix for plural entity queries (e.g., shares_collection, totals_collection). Standard GraphQL plural naming (shares) refers to the singular lookup requiring an id argument. If writing raw queries via query_lido_subgraph, use the _collection suffix to query multiple entities.
The Lido subgraph stores singleton entities (like protocol-wide totals) using an empty string as their ID. This is unusual but intentional. Raw queries for totals should use totals(id: "").
All data is queried from Lido's official subgraph deployed on The Graph's decentralized network. Every query generates fees for Indexers on the network. 13 active Indexers serve this subgraph.
Subgraph: Graph Explorer
Schema: GitHub
Docs: Lido Subgraph Docs
MIT
Get all Lido activity for a specific address: stETH balance, recent deposits, transfers (in/out), and withdrawal requests. Single view of an address's complete Lido interaction history
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of events per category (default 10) | |
| address | Yes | Ethereum address to look up |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It only lists the information categories, but does not disclose whether the operation is read-only, any rate limits, data freshness, or how empty results are handled. The term 'Get' suggests read-only, but it's not explicit.
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?
The description is two sentences with no redundant information, front-loaded with the primary action, and efficiently conveys the scope of data. Every word earns its place.
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?
The description covers the purpose and data categories, but without an output schema, more detail on the response structure would be helpful. It is adequate for a simple lookup tool but leaves some ambiguity about the output format.
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?
Both parameters have schema descriptions that fully cover their meaning (address and limit per category). The tool description does not add extra semantic value beyond what the schema provides, so the baseline score of 3 is appropriate.
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 clearly states it retrieves all Lido activity for a specific address, listing specific categories (stETH balance, deposits, transfers, withdrawal requests). It distinguishes itself from sibling tools like get_recent_transfers or get_withdrawal_requests by offering a comprehensive single view.
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 description implies this tool is for a complete overview of an address's Lido interactions, but does not explicitly state when to use it versus siblings, nor does it provide conditions like prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Lido EasyTrack motions. EasyTrack is a lightweight governance mechanism for routine operations (budget allocations, reward programs) that do not require full DAO votes
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of motions to return (default 10) | |
| status | No | Filter by status (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only describes purpose; missing details on read-only nature, pagination, rate limits, or any behavioral traits. Lacks behavioral context beyond the basic operation.
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 verb and resource, no unnecessary words. Highly efficient and easy to parse.
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?
Tool is simple with 2 optional params and no output schema. Description explains purpose and context adequately. Could mention return format, but not critical.
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% with clear descriptions for both parameters (limit and status). Description adds no extra meaning beyond schema, so baseline of 3 is appropriate.
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?
Clearly states verb 'Get' and resource 'Lido EasyTrack motions', and explains what EasyTrack is, distinguishing it from sibling tools like get_governance_votes.
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?
Describes that EasyTrack is for routine operations not requiring full DAO votes, providing context on when to use this tool. Does not explicitly state when not to use or list alternatives, but gives enough guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Lido DAO governance votes (Aragon voting). Shows proposal metadata, execution status, and individual votes
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of votes to return (default 10) | |
| executed | No | Filter by execution status (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only lists output content. Does not disclose behavioral traits like pagination, rate limits, or whether it is read-only. For a data retrieval tool, more transparency is needed.
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?
The description is a single, well-structured sentence with no wasted words. It front-loads the core purpose and then specifies the output, achieving maximum conciseness.
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?
Given the lack of output schema and annotations, the description is minimal. It explains what is returned but lacks details on ordering, pagination, or how filters affect results. Adequate for a simple list tool but not fully 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?
Input schema covers 100% of parameters with descriptions. The tool description does not add further meaning beyond what the schema provides, and no parameter details are missing. Baseline score of 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 clearly states the verb 'Get', the resource 'Lido DAO governance votes', and mentions 'Aragon voting' for context. It enumerates what is shown: proposal metadata, execution status, and individual votes, which distinguishes it from siblings like get_vote_details.
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?
No guidance on when to use this tool versus alternatives such as get_vote_details or other governance-related tools. Lacks explicit context or use-case direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Introspect the Lido subgraph GraphQL schema. Returns all available entity types and their fields. Useful for building custom queries
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It mentions returning the schema (read-only), but does not disclose potential side effects, rate limits, or data volume considerations. Adequate but not exhaustive.
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 concise sentences: first states the action and output, second adds context on usefulness. No redundant words, aptly 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?
Given no parameters, no output schema, and low complexity, the description covers the core purpose. However, it does not specify the return format (e.g., GraphQL SDL or introspection JSON), which could aid the agent.
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 has zero parameters, so the description's role is minimal. A baseline of 4 is appropriate as no parameter information is needed beyond what the schema conveys.
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 clearly states it introspects the Lido subgraph GraphQL schema, returns entity types and fields, and is useful for building custom queries. This distinctively differentiates it from siblings like query_lido_subgraph.
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 description implies usefulness for building queries but does not explicitly state when to use this tool versus alternatives (e.g., before query_lido_subgraph). No when-not-to-use or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current Lido protocol statistics: total pooled ETH, total shares, unique holders, fee structure, and withdrawal queue status
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It indicates a read-only fetch of current statistics, which is clear. However, it does not specify if data is real-time or cached, or any potential limitations, but for a simple getter with no parameters, this is acceptable.
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?
The description is a single sentence that is front-loaded with the action and key outputs. Every word adds value, with no redundancy. It is concise and well-structured.
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?
Despite no output schema, the description lists all expected return fields (total pooled ETH, shares, holders, fee structure, withdrawal queue status). For a zero-parameter tool with a simple purpose, this provides sufficient context. The sibling tools cover specialized queries, so this summary tool is complete as is.
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 has zero parameters, so the baseline is 4. The description adds no parameter information because none exist. This is appropriate as the schema coverage is 100%.
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?
Description clearly states the tool's action ('Get current Lido protocol statistics') and enumerates specific data points (total pooled ETH, shares, holders, fee structure, withdrawal queue). This distinguishes it from sibling tools that focus on specific aspects (e.g., get_staking_apr, get_node_operators), providing a clear purpose.
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?
No explicit usage guidance is provided, such as when to use this tool versus alternatives like get_staking_apr or get_node_operators. The context implies this is a general overview, but an explicit recommendation would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Lido node operators: names, staking limits, active status, stopped validators. These are the professional validator operators running Ethereum validators for Lido stakers
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of operators to return (default 50) | |
| active_only | No | Only show active operators (default true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states it is a read operation but omits details like pagination behavior, rate limits, or any side effects. The description adds minimal insight beyond the obvious.
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?
The description is two sentences, front-loaded with the core purpose, and every word adds value. There is no extraneous 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?
The description lacks details on the return structure (e.g., list format, sorting) and does not explain pagination or how limit interacts with total results. Given no output schema, more context would improve completeness.
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% with both parameters documented (limit and active_only). The description does not add additional context for parameters beyond what the schema provides, so it meets the baseline.
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 clearly states the tool retrieves Lido node operators and lists the specific data fields (names, staking limits, active status, stopped validators). It distinguishes itself from sibling tools by focusing exclusively on validator operators.
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 description does not explicitly state when to use this tool versus alternatives. While sibling tools are quite different, there is no guidance on prerequisites, filtering, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Lido oracle completed reports: beacon chain balance, validator count per epoch. Oracle reports trigger reward distribution and stETH rebase
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of reports to return (default 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions that oracle reports trigger reward distribution, but this is about the data's effect, not the tool's behavior. It does not state that the tool is read-only, require any authentication, or specify data freshness. The only behavioral hint is that it returns 'completed' reports.
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?
The description is two sentences with no superfluous words. It front-loads the main purpose and adds brief context about the data's significance. Could be slightly more concise by combining sentences, but it is efficient overall.
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 simple tool (one parameter, no output schema), the description is adequate but not fully complete. It explains what data is returned but does not specify the output format, ordering, or pagination (if any). Additional details on expected response structure would improve completeness.
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% and the schema fully describes the 'limit' parameter (type, range, default). The description does not add extra semantic meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
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 clearly states the verb 'Get', the resource 'Lido oracle completed reports', and specifies the content ('beacon chain balance, validator count per epoch'). It is distinct from sibling tools like 'get_node_operators' or 'get_withdrawal_requests', which target different data.
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?
No explicit guidance on when to use this tool versus alternatives. The description does not mention scenarios where another tool would be more appropriate, nor does it provide exclusions or context for selecting this over siblings such as 'get_recent_submissions' or 'get_lido_stats'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent stETH staking submissions (deposits). Shows who staked, how much ETH, shares received, and the effect on total pooled ether
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of submissions to return (default 20) | |
| min_amount_eth | No | Minimum stake amount in ETH to filter (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose behavioral traits such as ordering of results, pagination behavior, or any rate limits. It only describes the output content without side-effect details.
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?
The description is a single sentence that immediately states the purpose and lists key output details. Every word is meaningful; no filler or redundancy.
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 simple tool with two optional parameters and no output schema, the description is fairly complete. It explains what the tool does and what data it returns. However, it does not specify ordering (likely by time) or confirm read-only behavior, which would be helpful.
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 input schema has 100% coverage, describing both 'limit' and 'min_amount_eth' with defaults and ranges. The tool description adds context by mentioning 'min amount in ETH' and 'Number of submissions', but this mostly duplicates the schema. Baseline 3 is appropriate.
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 clearly states it retrieves recent stETH staking submissions (deposits) and lists the specific information shown (who staked, amount, shares, effect on total pooled ether). This is a specific verb+resource combination that distinguishes it from sibling tools like get_recent_transfers.
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 description implies usage for recent staking deposits but does not explicitly state when to use this tool versus alternatives (e.g., get_recent_transfers for transfers) or provide exclusions. No when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent stETH token transfers. Track large stETH movements between addresses
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of transfers to return (default 20) | |
| address | No | Filter by sender or receiver address (optional) | |
| min_value_eth | No | Minimum transfer value in ETH to filter (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not explicitly state read-only or non-destructive nature. Although 'get' implies safety, the description fails to disclose potential rate limits or data freshness.
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 concise sentences with no wasted words, front-loaded with primary purpose.
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?
Sufficient for a simple read tool with no required parameters and no output schema. Minor lack of detail on pagination or default ordering.
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 the schema already documents all parameters. Description adds minimal extra meaning beyond hinting at min_value_eth for large transfers.
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?
Describes specific verb 'Get' and resource 'recent stETH transfers', clearly distinct from sibling tools like get_address_activity or get_steth_ratio_history.
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?
Implies usage for tracking large stETH movements, but lacks explicit when-to-use vs alternatives or when-not-to-use. Still, the context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Lido staking APR history from oracle reports. Returns APR (after fees), APR before fees, total rewards, MEV fees, and fee breakdown per report period
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of reward reports to return (default 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the source ('oracle reports') and the type of data returned (historical APR per report period), but lacks details on pagination behavior, rate limits, or any side effects. The 'Get' verb implies read-only, but this is not explicit.
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?
A single sentence that is front-loaded with the verb and resource, followed by a concise list of return fields. No unnecessary words or redundancy. Every part adds 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?
Given the tool has only one optional parameter and no output schema, the description covers return fields adequately. However, it omits context like the specific staking protocol (Lido on Ethereum) and the period granularity (e.g., per report). Still, for a simple tool, it is nearly 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?
Schema coverage is 100% for the single parameter 'limit', which is already clearly described in the schema (number of reports, default 10, range 1-100). The tool description adds no additional semantics beyond what the schema provides, so baseline score of 3 is appropriate.
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 clearly states the verb 'Get' and the resource 'Lido staking APR history from oracle reports', specifying exact return fields (APR after fees, etc.). It is specific but does not explicitly differentiate from sibling tools like get_oracle_reports or get_lido_stats, though the context implies the distinction.
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?
No guidance on when to use this tool versus alternatives like get_oracle_reports or get_steth_ratio_history. The description does not mention exclusions or prerequisites, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate net staking flow: compare recent deposits (submissions) vs withdrawal requests to determine if Lido is growing or shrinking. Returns totals for each side and the net direction
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of recent events to compare per side (default 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses return structure (totals per side and net direction) but lacks details on side effects, data freshness, or pagination.
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 concise sentences front-loaded with purpose, no redundancy.
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 simple tool with one parameter and no output schema, the description covers purpose and return value; minor omission on how net direction is calculated.
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% for the single parameter. Description adds 'per side' context beyond the schema, which is mildly helpful but not substantial.
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?
Description clearly states the tool calculates net staking flow by comparing deposits and withdrawals, distinguishing its aggregated nature from sibling tools that focus on single sides (e.g., get_recent_submissions, get_withdrawal_requests).
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?
Description implies usage for assessing Lido growth/shrinking but does not explicitly state when to use this tool over alternatives or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the historical stETH/ETH exchange ratio derived from oracle reward reports. Shows how stETH appreciates over time relative to ETH as staking rewards accrue. The ratio should always be >= 1 and slowly increasing
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of data points (default 30, one per oracle report ~daily) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description discloses the ratio source, expected monotonic increase, and minimum value. It is transparent about the behavioral traits but could explicitly state it's a read-only operation.
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 key action, no extraneous text. Every sentence adds 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?
For a simple tool with one optional parameter and no output schema, the description adequately explains the concept and expected behavior. It could be improved by mentioning the output format (e.g., array of ratios and timestamps) but is sufficient.
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% and the description adds no extra meaning beyond what the input schema provides for the 'limit' parameter (default, min, max, frequency). Baseline of 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 clearly states the tool retrieves historical stETH/ETH exchange ratio derived from oracle reward reports, explaining its purpose and behavior. It distinguishes itself from sibling tools which focus on other Lido-related data points.
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?
No guidance on when to use this tool versus alternatives (e.g., get_staking_apr, get_oracle_reports). The description lacks exclusions or context for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the largest stETH holders ranked by share balance. Shows addresses, share count, and estimated stETH value. Useful for tracking whale concentration and institutional holders
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of holders to return (default 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It implies a read operation via 'Get' and describes output, but does not explicitly state read-only nature, rate limits, or other behavioral traits. For a simple query tool, this is minimally adequate.
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 concise sentences with no redundancy. The first sentence front-loads the core action and resource, and the second adds output details and use case. Every word earns its place.
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 simple tool with one optional parameter and no output schema, the description is mostly complete. It states what is returned and a typical use case. Minor gap: does not clarify how 'estimated stETH value' is derived, but this is acceptable.
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 schema covers 100% of parameters with a description for 'limit'. The tool description adds no additional meaning beyond the schema's parameter description. Baseline 3 is appropriate.
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 uses a specific verb ('Get'), names the resource ('largest stETH holders'), and states the ranking criterion ('by share balance'). It also lists the output fields, clearly differentiating from sibling tools like 'get_holder_shares' which likely targets individual holders.
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 description mentions usefulness for 'tracking whale concentration and institutional holders', implying a use case. However, it does not explicitly state when to prefer this over alternatives (e.g., get_holder_shares) or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed voting records for a specific Lido DAO governance vote. Shows all individual voter addresses, their vote direction, and stake weight
| Name | Required | Description | Default |
|---|---|---|---|
| vote_id | Yes | The vote index number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It clearly indicates a read operation returning details, with no mention of destructive actions. Could be improved by explicitly stating it is read-only or noting any authorization requirements, but current transparency is good.
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?
The description is a single sentence that packs purpose and output specifics without any redundant words. It is front-loaded and efficient, earning its place.
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?
Given the simple schema (1 required param) and no output schema, the description adequately explains what the tool does and the data returned. It could mention the output format or provide an example, but overall sufficient.
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% with one parameter ('vote_id') described as 'The vote index number'. The description does not add extra meaning beyond the schema, but the schema itself is sufficient. Baseline score of 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 clearly states the verb 'get' and the resource 'detailed voting records for a specific Lido DAO governance vote', and specifies what is shown (voter addresses, vote direction, stake weight). It distinguishes from siblings like 'get_governance_votes' which likely lists votes, making the purpose unambiguous.
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 description implies usage when needing details of a specific vote, but does not explicitly state when to use this tool versus alternatives like 'get_governance_votes' or 'get_address_activity'. No when-not-to-use or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent claimed (completed) withdrawals. Shows who received ETH back after the withdrawal queue processed their request
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of claims to return (default 20) | |
| owner | No | Filter by owner address (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions 'recent' but does not clarify sorting, pagination, or side effects (e.g., read-only). The description lacks details on rate limits, authentication, or what constitutes 'recent'.
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?
The description is two concise sentences with no extraneous information. The first sentence front-loads the main purpose, making it immediately scannable.
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 simple tool with two optional parameters and no output schema, the description covers the core functionality adequately. It lacks info on authentication or pagination details, but these are partly covered by the schema's limit parameter.
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%; both parameters (limit and owner) have descriptions in the schema. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
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 clearly states 'Get recent claimed (completed) withdrawals. Shows who received ETH back after the withdrawal queue processed their request'. It uses a specific verb ('Get'), identifies the resource ('withdrawal claims'), and distinguishes from siblings like 'get_withdrawal_requests' by explicitly noting 'claimed (completed)'.
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 description implies usage for completed withdrawals but does not explicitly state when to use this tool versus alternatives like 'get_withdrawal_requests' or 'get_withdrawals_finalized'. No when-not or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent stETH withdrawal requests. Shows who is requesting to unstake, how much stETH, and the shares being burned
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of requests to return (default 20) | |
| owner | No | Filter by owner address (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only describes the output content, not behavioral traits like data freshness, idempotency, or pagination behavior beyond the limit parameter. Minimal disclosure.
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 the action and resource. No extraneous information. Efficiently conveys the essential purpose.
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?
Given the simple parameter set and no output schema, the description is adequate but incomplete. It does not mention ordering, pagination beyond limit, or error handling. With many sibling tools, more context could help, but it's sufficient for basic use.
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% (both parameters have descriptions). The tool description adds no additional parameter semantics beyond what the schema already provides, so it meets the baseline.
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?
Description clearly states the tool retrieves recent stETH withdrawal requests and specifies the information shown (who, amount, shares burned). It distinguishes from siblings like get_withdrawal_claims or get_withdrawals_finalized by focusing on pending requests.
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?
No explicit guidance on when to use this tool versus alternatives. While the title and description imply it's for viewing recent requests, it does not mention exclusions or when other tools (e.g., get_withdrawal_claims) would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get withdrawal finalization batches. Shows when the protocol finalized withdrawal request ranges, locking ETH and burning shares
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of finalization events to return (default 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses that the tool shows 'when the protocol finalized withdrawal request ranges, locking ETH and burning shares', which adds behavioral context. However, it does not explicitly state that it is a read-only query or mention any side effects, rate limits, or idempotence. The description is adequate but not comprehensive.
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?
The description is very concise at two sentences with no wasted words. It front-loads the main purpose and then adds clarifying detail. Every sentence earns its place.
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 simple tool with one optional parameter and no output schema, the description is largely complete. It explains what data is shown and the context (finalization, locking ETH, burning shares). It could mention the return format (e.g., list of events) or pagination behavior, but given the simplicity, it is still effective.
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% (the only parameter 'limit' is described in the schema). The tool description does not add any additional meaning beyond what the schema provides. According to the guidelines, when schema_description_coverage is high, baseline is 3, so this score is appropriate.
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 clearly states the tool retrieves 'withdrawal finalization batches' and explains that it shows when the protocol finalized withdrawal request ranges, locking ETH and burning shares. This is a specific verb and resource, and it distinguishes itself from sibling tools like get_withdrawal_claims and get_withdrawal_requests.
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 description implies its usage: to get withdrawal finalization batches. However, it does not provide explicit guidance on when to use this tool versus siblings (e.g., 'use this for finalized batches, use get_withdrawal_requests for pending requests'). No 'when not to use' or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run any raw GraphQL query against the Lido subgraph. Escape hatch for advanced queries not covered by other tools. Use get_lido_schema first to discover available entities and fields
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | GraphQL query string | |
| variables | No | Optional GraphQL variables as a JSON object |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the action but does not disclose whether the tool is read-only, authentication needs, or error handling. The raw query nature is implied but lacks details on behavioral constraints.
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 concise sentences, no fluff. First sentence states action, second gives usage guidance. Highly efficient.
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 raw query tool, the description provides essential context: purpose, when to use, and prerequisite. Missing explicit read-only assumption and output format, but adequate given it's an escape hatch and output schema is not provided.
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 description adds little beyond what schema provides. The description mentions 'raw GraphQL query' but doesn't add format details or examples. Baseline 3 is appropriate as schema already documents parameters.
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 clearly states it runs raw GraphQL queries against the Lido subgraph, serving as an escape hatch for advanced queries. This differentiates it from sibling tools that are specialized for specific data endpoints.
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 says to use when other tools don't cover the query, and advises using get_lido_schema first to discover entities and fields, providing clear when-to-use and prerequisite guidance.
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.
v1.0.0get_address_activityget_easytrack_motionsget_governance_votesget_holder_sharesget_lido_schemaget_lido_statsget_node_operatorsget_oracle_reportsget_recent_submissionsget_recent_transfersget_shares_burnsget_staking_aprget_staking_net_flowget_steth_ratio_historyget_top_holdersget_vote_detailsget_withdrawal_claimsget_withdrawal_requestsget_withdrawals_finalizedquery_lido_subgraphScored across 20 tools
Each tool targets a specific Lido protocol aspect (address activity, governance, withdrawals, etc.) with clearly distinct purposes. No overlapping functionality; even related tools like withdrawal requests and claims are well-separated.
All tools follow a consistent verb_noun pattern with underscores (e.g., get_address_activity, get_governance_votes). The outlier query_lido_subgraph also follows verb_noun, maintaining the pattern.
20 tools appropriately cover the multifaceted Lido protocol (staking, withdrawals, governance, node operations, etc.) without being overwhelming. Each tool earns its place.
The tool set comprehensively covers Lido's read-only surface: deposits, withdrawals, governance, monitoring stats, transfers, and edge cases via raw subgraph queries. No obvious gaps for the intended domain.
MCP server connecting AI agents to non-custodial staking data across 130+ networks.
MCP server for Renzo protocol data, including chains, vaults, operators, and ezETH metrics.
The Graph MCP — indexed blockchain data via subgraph GraphQL queries
Hosted MCP server for live Bittensor chain reads and self-custodial on-chain writes.
