web3-docs
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| WEB3_DOCS_DATA_DIR | No | Where source repos and the SQLite index live (default: ~/.cache/web3-docs-mcp on macOS/Linux) | ~/.cache/web3-docs-mcp |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| resolve_proposalA | 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. |
| resolve_contractB | 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. |
| list_fork_proposalsA | 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". |
| query_protocol_docsA | 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" |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each 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.