Provides access to Bitcoin Improvement Proposals (BIPs), enabling searches and retrieval of spec texts for proposals like BIP-340, and listing proposals activated by forks such as Taproot.
Integrates Cardano Improvement Proposals (CIPs), allowing queries about proposals like CIP-25 for native tokens and retrieval of their full spec bodies.
Offers canonical contract address lookups for Chainlink on multiple EVM chains, including Ethereum, Arbitrum, Base, and Optimism.
Provides access to Ethereum Improvement Proposals (EIPs) and ERCs, enabling searches for proposals like EIP-1559, EIP-4844, and listing all proposals activated by specific forks (e.g., Cancun, Pectra).
Supports querying of canonical contract addresses for protocols like Uniswap, USDC, and others on Optimism, alongside general proposal search across the web3-docs index.
Integrates Polkadot RFCs, allowing searches for proposals such as staking-related RFCs and retrieval of their specification texts.
Provides canonical contract address lookups for protocols on Polygon, including Aave, Uniswap, Chainlink, and others.
Integrates Solana Improvement Documents (SIPs), enabling searches for proposals and retrieval of spec content.
Offers access to Sui Improvement Proposals (SIPs), allowing searches and retrieval of proposal details.
Click on "Install 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., "@web3-docs look up EIP-1559"
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.
One MCP server, eleven protocol-spec repos. Ask your coding agent about EIPs, BIPs, ADRs, CIPs, RFCs and canonical contract addresses — without ever leaving your editor. Works with any MCP-compatible client: Claude Code, Cursor, Windsurf, Cline, Zed, Continue, OpenCode, Codex, and more.
Or replay in your own terminal: asciinema play docs/assets/demo.cast
Specs for blockchain protocols live across eleven different upstream repos on three different forges. Every time you need to look up EIP-4844, BIP-340, CIP-25, or which fork shipped PUSH0, you're tab-hunting through GitHub. This MCP indexes them all locally with FTS5 ranking — 1,767 proposals across 10 chains plus addresses for 19 protocols on Ethereum, Arbitrum, Base, Optimism, Polygon, and more — so your agent answers with the actual spec text, not a hallucinated paraphrase.
Related MCP server: yksanjo/gmem
Requires: Python 3.11+ ·
uv(providesuvx) · ~500 MB free disk for the index ·giton PATH (used by--sync).
~/.cache/web3-docs-mcp/)uvx web3-docs-mcp --syncThe launch command is identical across clients:
uvx web3-docs-mcpclaude mcp add web3-docs -- uvx web3-docs-mcpAdd to the client's MCP config (~/.cursor/mcp.json, ~/.codeium/windsurf/mcp_config.json, cline_mcp_settings.json, the mcpServers block in your Zed settings.json, etc.):
{
"mcpServers": {
"web3-docs": {
"command": "uvx",
"args": ["web3-docs-mcp"]
}
}
}codex mcp add web3-docs -- uvx web3-docs-mcppip install web3-docs-mcp
# or:
pipx install web3-docs-mcpgit clone https://github.com/dioptx/web3-docs.git && cd web3-docs
uv sync
uv run python server.py --sync # build index
uv run python server.py # run stdio serverRestart your agent, then try "Use web3-docs to look up EIP-1559."
Ask your agent… | Tool chain |
"What's the fee market in EIP-4844?" |
|
"Show me Cosmos ADR-001." |
|
"What's in Cancun?" |
|
"Which BIPs activated with Taproot?" |
|
"Uniswap router on Base?" |
|
"Cardano CIP for native tokens?" |
|
"ERC-4337 EntryPoint address on Arbitrum?" |
|
"Staking on Cosmos vs Polkadot?" |
|
Multi-chain canonical addresses, no etherscan tabs.
Tool | What it does |
| Fuzzy-find a proposal by keyword, fork name, opcode, or ID. Returns top-5 ranked hits with chain/status/fork. Pass |
| Read the full spec body. With |
| List every proposal activated by a named fork. Answers "what's in Cancun?" / "BIPs activated with Taproot?". Handles aliases (Pectra → Prague, Dencun → Cancun, Shapella → Shanghai, The Merge → Paris). |
| Look up canonical deployed addresses. 19 protocols × major EVM chains. Omit |
Fork → all proposals it shipped, then drill into one. Two tool calls instead of an afternoon of tab-hunting.
11 upstream repos, all synced via --sync:
Chain | Source |
Ethereum (EIPs) | |
Ethereum (ERCs) | |
Bitcoin | |
Solana | |
Cosmos |
|
Polkadot | |
Stacks | |
Avalanche | |
Cardano | |
Tezos | |
Sui |
Fork mappings come from ethereum/execution-specs plus canonical Bitcoin soft-fork activations (P2SH, SegWit, Taproot, …).
Contract registry covers: aave, across, chainlink, compound, create2_deployer, curve, ens, erc4337, gnosis_safe, lido, maker, multicall, oneinch, permit2, seaport, uniswap, usdc, usdt, weth.
…just gh search or WebFetch each spec on demand? You'd burn tokens on HTML markup and pay a network round-trip per query. web3-docs indexes everything once into local SQLite + FTS5 — sub-millisecond ranked search, plain-text bodies, no rate limits, works offline.
…one MCP per chain? You'd manage eleven separate servers and your agent wouldn't know which to call. One unified tool with a single resolve_proposal entry point lets the model find the right doc by concept (e.g. "blob transactions" → eip-4844) rather than guessing the source.
…ask the model directly without an MCP? Models hallucinate spec details — wrong fork, wrong gas costs, wrong opcode numbers. This server returns the actual upstream text with metadata (status, fork, activation date) so the agent can quote it verbatim.
…use a vector DB? Spec corpora are small (≈ 1.7K docs), domain vocabulary is precise (PUSH0, BLOBHASH, taproot), and exact-term matching beats embeddings here. FTS5 gives BM25 ranking with zero infrastructure.
Env var | Default | Purpose |
|
| Where source repos and the SQLite index live |
"Index is empty" on any tool call. You haven't run --sync yet. Run:
uvx web3-docs-mcp --syncuvx: command not found. Install uv: curl -LsSf https://astral.sh/uv/install.sh | sh.
Want to free disk space? Source repos (~/.cache/web3-docs-mcp/repos/) can be deleted after sync; only proposals.db is needed at runtime. Re-run --sync to update.
Stale data? Re-run --sync — it does a fast git pull and reindexes incrementally.
git clone https://github.com/dioptx/web3-docs.git && cd web3-docs
uv sync --extra test
uv run pytest # 98 tests, BDD + unit
uv build # build wheel + sdistv0.2.0 — adds Cardano CIPs, Tezos TZIPs, Sui SIPs (10 chains, 1,767 proposals). SQLite + FTS5, FastMCP stdio transport. See CHANGELOG.md for release history.
MIT — see LICENSE.
List every proposal activated by a named blockchain fork.
The unique value of this server: maps proposals → forks. Use this to answer "What's in Cancun?", "Which BIPs activated with Taproot?", "What does Shanghai include?" — anything that would otherwise require manually cross-referencing fork meta-EIPs.
Covers Ethereum forks (Frontier through Prague/Pectra) and Bitcoin soft-fork activations (P2SH, BIP66, CSV, SegWit, Taproot).
Args: fork_name: Fork name. Accepts canonical and consensus-layer aliases. Examples: "Cancun", "Dencun", "Shanghai", "Shapella", "Prague", "Pectra", "Paris", "The Merge", "Taproot", "SegWit", "London", "Berlin".
| Name | Required | Description | Default |
|---|---|---|---|
| fork_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adequately discloses the tool's read-only nature and scope of coverage. It does not mention auth or rate limits, but these are not expected for a listing tool. The description is transparent about what it does and does not do.
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 well-structured, starting with purpose, then unique value, scope, and parameter details. Every sentence adds value without verbosity, making it 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?
Given the tool's simplicity (single parameter, output schema present), the description is complete. It clearly explains the query type, supported forks, and parameter format. The output schema covers return values, so no further explanation is needed.
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 has zero descriptions for the 'fork_name' parameter. The description compensates fully by providing examples of valid fork names (e.g., 'Cancun', 'Taproot') and noting it accepts canonical and consensus-layer aliases, adding significant meaning 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?
The description clearly states 'List every proposal activated by a named blockchain fork' and emphasizes the unique value of mapping proposals to forks, distinguishing it from sibling tools like query_protocol_docs, resolve_contract, and resolve_proposal.
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 provides explicit use cases (e.g., 'What's in Cancun?') and scope (Ethereum and Bitcoin forks). While it lacks explicit when-not-to-use or alternative tool names, it effectively contrasts with manual cross-referencing, giving clear context for when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the specification of a blockchain protocol proposal.
Returns a compact metadata header plus the proposal body. When a query is provided, returns only the most relevant sections (saves tokens). Without a query, returns the full text (truncated to 4K chars — use a query to get specific sections of long proposals).
Args: proposal_id: Proposal ID from resolve_proposal. Examples: "eip-1559", "bip-341", "erc-20" query: Optional focus question. Examples: "base fee calculation", "security", "backwards compatibility"
| Name | Required | Description | Default |
|---|---|---|---|
| proposal_id | Yes | ||
| query | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: return structure (metadata header + body), truncation at 4K chars without query, token-saving behavior with query. No contradictions or omissions.
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 well-structured with purpose first, then behavioral details, then parameter list. Slightly lengthier than necessary due to examples, but 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?
Given the tool's simplicity and presence of an output schema, the description sufficiently covers return structure and behavior under different query conditions, providing complete context for correct invocation.
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 0%, but the description adds substantial meaning: example values for proposal_id ('eip-1559', 'bip-341', 'erc-20') and query ('base fee calculation', 'security') clarify expected inputs beyond basic type/required info.
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 'Read the specification of a blockchain protocol proposal' with a specific verb and resource. It distinguishes from siblings like list_fork_proposals (lists proposals) and resolve_proposal (resolves ID), making 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 explicitly explains when to use the query parameter: 'with a query returns only relevant sections (saves tokens); without query returns full text truncated to 4K chars'. It also references resolve_proposal as the source of proposal_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up canonical deployed contract addresses for Web3 protocols.
Covers: Uniswap, Aave, Compound, Curve, ENS, Lido, Maker, WETH, USDT, USDC, Multicall3, ERC-4337 EntryPoint, Gnosis Safe, Permit2, Seaport, 1inch, Across, Chainlink, CREATE2 Deployer. Multi-chain (Ethereum, Arbitrum, Base, Optimism, Polygon, etc.)
Args: protocol: Protocol name. Examples: "uniswap", "weth", "usdc", "aave", "safe" chain_id: Optional chain ID filter. "1"=Ethereum, "42161"=Arbitrum, "8453"=Base, "10"=Optimism, "137"=Polygon. Omit for all chains.
| Name | Required | Description | Default |
|---|---|---|---|
| protocol | Yes | ||
| chain_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It implies a read-only lookup but does not mention rate limits, authentication requirements, error handling, or what happens if the protocol/chain is unsupported. Minimal behavioral context beyond the core 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?
The description is well-structured with a concise summary sentence followed by a bullet list of supported protocols, chains, and argument details. It is front-loaded with the core purpose. 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?
Given the tool's moderate complexity (many protocols and chains, optional chain_id, output schema exists), the description is fairly complete. It covers the main inputs and what the tool returns (contract addresses). The presence of an output schema reduces the need to describe return format in detail. Some edge cases (e.g., case sensitivity of protocol names) are not addressed, 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 description coverage is 0%, so the description must compensate. It does so effectively by explaining both parameters: 'protocol' with multiple examples and 'chain_id' with optional usage, examples for common chains, and the effect of omission. This adds significant meaning beyond the schema's basic type/title.
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 looks up canonical deployed contract addresses for Web3 protocols, with a specific verb ('look up') and resource ('contract addresses'). It lists supported protocols and chains, making the purpose unambiguous. However, it does not explicitly differentiate from sibling tools like resolve_proposal or query_protocol_docs, which could clarify when to use this over others.
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 provides examples of argument usage (protocol, chain_id) but offers no guidance on when to use this tool versus alternatives, nor any conditions or prerequisites. For an agent to decide, explicit usage scenarios or exclusions would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find blockchain protocol proposals by keyword, concept, or proposal number.
Searches across EIPs, ERCs, BIPs, SIMDs, Cosmos ADRs, Polkadot RFCs, Stacks SIPs, Avalanche ACPs, Cardano CIPs, Tezos TZIPs, Sui SIPs. Returns ranked results with fork info and status. Use the returned ID with query_protocol_docs to read the full spec.
Args: query: What to search for. Accepts concept names, keywords, proposal IDs, fork names, or opcode names. Examples: "fee market", "ERC-721", "taproot", "blob transactions", "PUSH0", "London fork", "CIP-25", "FA2 token", "sui object" chain: Optional chain filter for disambiguation. One of: ethereum, bitcoin, solana, cosmos, polkadot, stacks, avalanche, cardano, tezos, sui. Use when a keyword (e.g. "staking", "governance") could match multiple chains. Omit to search all.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| chain | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it searches across many protocols, returns ranked results with fork info and status, and does not read full specs. No annotations provided, but description sufficiently conveys read-only search behavior.
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?
Well-structured with summary, details, examples, and parameter docs. Slightly lengthy but every sentence contributes 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?
Complete for a search tool: covers search scope, return format, parameter guidance, and connection to sibling tools. Output schema exists, so return values need not be detailed.
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?
Despite 0% schema coverage, description thoroughly explains both parameters: query with multiple examples and chain with valid values and usage guidance, adding significant value 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?
Clearly states the tool finds blockchain protocol proposals by keyword, concept, or number. Distinguishes from siblings by mentioning use of returned ID with query_protocol_docs.
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?
Provides explicit examples and guidance on chain filter usage, including when to omit. Lacks explicit when-not-to-use scenarios but adequately covers context.
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. Dates show when Glama detected each change.
v0.2.1list_fork_proposalsquery_protocol_docsresolve_contractresolve_proposalEach tool targets a distinct aspect of Web3 documentation: forks, proposal discovery, proposal reading, and contract addresses. No overlap in functionality.
All tools follow a consistent verb_noun pattern with underscores (e.g., list_fork_proposals, resolve_proposal), making them predictable and easy to understand.
Four tools is a compact yet complete set for the server's purpose—covering fork proposals, proposal search/reading, and contract resolution—without unnecessary bloat.
The tool surface covers the full workflow: find proposals (resolve_proposal), read them (query_protocol_docs), list fork contents (list_fork_proposals), and look up deployed contracts (resolve_contract). No obvious gaps for the stated domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Token-efficient search for coding agents over public and private documentation.
Verified doc corpora for agents: grep-first retrieval, hashed pages, Merkle+RFC-3161 receipts
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…
Codebase intelligence for agents: 152 structured artifacts across 21 programs, one call.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dioptx/web3-docs'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
