← EtherscanCONTENT HISTORYWHAT CHANGED · RULE-BASED ANALYSIS
Update to Etherscan
Snapshot Sep 30, 2026 · 23:11 UTC · version 1.0.0
Collection source: not recorded for this historical snapshot.
First saved snapshot
No earlier snapshot is available to establish a change.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"name": "etherscan",
"description": "Use Etherscan's hosted MCP tools to inspect public EVM blockchain data. Use for wallet balances and activity, token transfers and holders, transaction details or status, contract source and ABI, event logs, blocks, gas, address labels, funding sources, and supported-chain discovery.",
"included_files": [],
"skill_md_contents": "---\r\nname: etherscan\r\ndescription: >-\r\n Use Etherscan's hosted MCP tools to inspect public EVM blockchain data. Use\r\n for wallet balances and activity, token transfers and holders, transaction\r\n details or status, contract source and ABI, event logs, blocks, gas, address\r\n labels, funding sources, and supported-chain discovery.\r\n---\r\n\r\n# Etherscan MCP\r\n\r\nUse the connected `etherscan` MCP server as the live authority. The server is\r\nhosted at `https://mcp-keyless.etherscan.io/mcp`, is read-only, and requires no API key.\r\nDo not ask the user for a key.\r\n\r\n## Workflow\n\n### Interactive Etherscan UI fast path\n\nWhen the user asks for an interactive Etherscan view, dashboard, card, or\nvisual result, `render_etherscan_widget` is the complete visualization path.\nDo not invoke, inspect, or compose a general visualization skill or a separate\nvisualization tool. Retrieve only the requested Etherscan facts, then call\n`render_etherscan_widget` immediately; do not perform additional analysis or\npresentation work between the final data result and the render call.\n\n1. Inspect the currently advertised Etherscan tools and their schemas. Do not\n assume that a documented tool is still available.\r\n2. Identify the target type: address, transaction hash, token contract,\r\n contract, block, timestamp, or event topic.\r\n3. When the user does not specify a chain, use Ethereum Mainnet (`chainid`\n `\"1\"`) and state that default briefly. Never guess another chain from the\n first activity found, and never probe or scan multiple chains automatically.\n Use `get_supported_chains` only when the user names a chain but its numeric\n chain ID or Etherscan support is unknown; do not infer support from EVM\n compatibility. Query multiple chains only when the user explicitly asks for\n multichain results.\n4. Call the narrowest matching data tool. Optimize for a fast first result:\r\n do not fetch holdings, transaction history, labels, funding sources, or\r\n charts merely to decorate a wallet balance response. Use conservative\r\n pagination when the user actually requests an activity list, and say when\r\n the result is truncated or paginated.\r\n5. Unless the user requests plain JSON or text only, call\n `render_etherscan_widget` immediately after the minimum data needed for the\n answer is available. Copy only facts present in tool results. For a basic\r\n wallet request, a balance-only widget is complete; wallet activity and token\r\n holdings are optional and must not be fetched unless the user asks for them\r\n or they are necessary to answer the question. Put the primary value first\r\n in `metrics`; use `sections` with `cards` for requested holdings or summary\r\n groups, `rows` for requested activity, and `chips` for short tags. Include\r\n `chart` only when the user needs a trend and every point came from a live\n tool response.\n6. After the widget call, explain the returned facts briefly in plain language.\n Preserve addresses, hashes, amounts, status values, timestamps, and API\n errors exactly enough for the user to verify them.\n\r\n## Presentation rules\r\n\r\n- Never invent security scores, risk labels, historical prices, forecasts,\r\n labels, identities, or audit conclusions.\r\n- Never claim that an address owns an identity unless Etherscan returned that\r\n label or the user supplied it.\r\n- State units explicitly. Convert Wei or Unix timestamps only when the\r\n conversion is deterministic, and retain the original value when useful.\r\n- Add an explorer URL to the widget only when the correct explorer host for the\r\n selected chain is known from live Etherscan data or the user supplied it.\r\n- Treat an empty result as \"no records returned for this query,\" not proof that\r\n no activity exists outside the requested range or supported data surface.\r\n- Never synthesize chart points from only a current value or a start/end value.\r\n\r\n## Boundaries\r\n\r\nThe MCP server cannot sign or broadcast transactions, verify contracts, manage\r\nAPI keys, or change blockchain or Etherscan state. If a user asks for a write,\r\nexplain this boundary and offer a read-only inspection that helps them prepare\r\nor verify the action.\r\n\r\nKeep transport failures, schema validation failures, and Etherscan API errors\ndistinct. Do not retry repeatedly when the server reports throttling or a plan\nrestriction. If a throttling error includes `retryAfter`, `rateLimitReset`, or\nother rate-limit details, report the available retry timing rather than\nguessing one.\n"
}SHA-256: 0752049621a8bb41481dbb194e5a3d4784b5e0768ae10f5bd1c0605f215f4f31