Snapshot DAO (Free)
Snapshot DAO governance, free and non-gated: browse spaces, proposals, and votes, then build the EIP-712 vote the user signs with their own wallet and relay it to the sequencer. The server never signs, never holds keys. Rate-limited. By Yeetful.
Routability
can the router discover, pick, and call it?14 checks
- schema · 6 endpoints are planner-eligible
- schema · param-schema coverage 6/8 endpoints (75%)
- schema · typed params 11/11
- schema · required flags present
- description · 6/6 endpoint descriptions carry real intent
- description · capability tags: governance-dao
- description · 3 example queries
- probe · https://snapshot-mcp.yeetful.com/mcp → HTTP 200
- planner · "What DAO votes are active right now?" → picked + constructed (tools/call)
- planner · "Show me the details and current voting breakdown for the Uniswap governance proposal on tokenomics" → picked + constructed (tools/call)
- planner · "How do I vote on this Snapshot proposal with my wallet?" → planner picked NOTHING
- affordances · identity params documented for context vars ($USER_ADDRESS)
- affordances · general query escape hatch present
- affordances · signing hygiene: build-don't-execute language (or no signables)
Suggested fixes
- The planner declined "How do I vote on this Snapshot proposal with my wallet?" against this service's own menu — the endpoint descriptions don't signal that capability.
Fix it with Claude Code
Paste this into Claude Code inside the MCP’s repo — it carries the failing checks, the fix list, and the conventions the router grades against.
You are upgrading the MCP service "Snapshot DAO (Free)" so an AI router can reliably discover, choose, and call its tools. Pantessa's Reason Router just graded it 88/100 (A). I'll point you at the service's codebase; audit it against the findings below and implement the fixes.
## Failing checks
planner (67%):
- "How do I vote on this Snapshot proposal with my wallet?" → planner picked NOTHING
## Fixes, in priority order
1. The planner declined "How do I vote on this Snapshot proposal with my wallet?" against this service's own menu — the endpoint descriptions don't signal that capability.
## The conventions to build to (what the router needs)
- **Param schemas on every tool/endpoint**: name, type, required-vs-optional, and a description per param. A router refuses to construct calls it cannot validate — schema-less endpoints are invisible.
- **Descriptions that carry user intent**: write what a USER would ask ('crypto spot price by symbol — price of ETH, BTC…'), never what the URL is. Include 2–3 example queries.
- **One guarded escape hatch instead of endless params**: if the backend has a native query language (GraphQL/SQL), expose ONE read-only general-query tool with strict guardrails (single read-only operation, allowlisted root fields, depth + page-size caps, response truncation) and a compact schema card in the tool description (root fields + useful filters + one example). Long-tail intents then need no new endpoints.
- **Declare user-identity params**: any param that should be the CALLER's own address (their votes, follows, balances, orders) must say so in its description ('the user's own wallet address') so routers can inject identity server-side instead of guessing.
- **Server-side joins for the headline intent**: if answering the #1 user question takes two chained calls (e.g. resolve follows → filter proposals), add one param that does the join server-side.
- **Build, don't execute**: anything signable returns an UNSIGNED payload (typed data / tx template) for the user's own wallet. Never hold keys, never sign, never submit on the user's behalf.
- **Free tiers still need rate limiting**: no payment gate means no natural throttle.
Start by reading the tool/endpoint definitions and their input schemas, then apply the fixes smallest-first. After each change, restate which failing check it clears.
Audit before you build: if a fix describes a capability the service ALREADY provides (e.g. an escape hatch or identity param that exists but the grader missed), do NOT duplicate it — say so, skip it, and note it back as a likely router-side scoring gap on Pantessa rather than an MCP deficiency. Only change what this service actually controls.Tools
8- POST/mcp/list_proposalsstart herevia Yeetful (free)snapshot-mcp.yeetful.com
Recent Snapshot governance proposals. Filter by space, state, and/or follower (an EVM address — only proposals in spaces that address follows; 'what can I vote on' / 'do I have open proposals' = follower:"$USER_ADDRESS" + state:"active"). Default (no args) = active proposals across all DAOs — answers 'what DAO votes are live right now'.
4 parameters
- spacestringbody
Snapshot space id, e.g. ens.eth.
- statestringbody
Proposal state filter. Use "active" for open/live votes.
- followerstringbody
EVM address — scope to the spaces this address follows (the user's own governance feed → "$USER_ADDRESS").
- firstnumberbody
Max results.
- POST/mcp/list_spacesstart herevia Yeetful (free)snapshot-mcp.yeetful.com
Browse and discover DAO governance spaces on Snapshot, most-followed first — which DAOs exist, top DAOs by followers, find a DAO to join or watch.
1 parameter
- firstnumberbody
Max results.
- POST/mcp/get_proposalvia Yeetful (free)snapshot-mcp.yeetful.com
Full detail for one proposal: choices, scores, state, window.
1 parameter
- idstringbodyrequired
Proposal id (0x… hash).
- POST/mcp/list_votesvia Yeetful (free)snapshot-mcp.yeetful.com
Votes cast on a proposal, by voting power.
2 parameters
- proposalstringbodyrequired
Proposal id (0x… hash).
- firstnumberbody
Max results.
- POST/mcp/get_spacevia Yeetful (free)snapshot-mcp.yeetful.com
DAO space metadata (name, network, proposal/follower counts).
1 parameter
- idstringbodyrequired
Space id, e.g. ens.eth.
- POST/mcp/graphql_queryvia Yeetful (free)snapshot-mcp.yeetful.com
Escape hatch — any READ-ONLY GraphQL query against the Snapshot hub when the other tools lack the filter (author, time windows, follows, voting power, vote-by-voter…). Root fields: proposals, votes, spaces, follows, subscriptions, users, vp, ranking, messages, strategies, networks, aliases. Where-filters: proposals(space_in, state, author, title_contains, start_gte/lte, end_gte/lte) · votes(proposal, voter, space_in, vp_gte) · follows(follower, space_in). List args: first(≤100), skip, orderBy("created"|"vp"|…), orderDirection. Put user values in variables; "$USER_ADDRESS" works inside variables for the user's own address.
2 parameters
- querystringbodyrequired
GraphQL query document — ONE read-only query operation, e.g. query($f:String!){ follows(where:{follower:$f}){ space { id name } } }
- variablesstringbody
GraphQL variables as a JSON object string, e.g. {"f":"$USER_ADDRESS"}.
- POST/mcp/prepare_votevia Yeetful (free)snapshot-mcp.yeetful.com
Build the EIP-712 typed data for a Snapshot vote, ready for the voter to sign. Provide choice (1-indexed) or choiceText ("For", "yes", "option 2"). Returns typed data + human summary.
- POST/mcp/submit_votevia Yeetful (free)snapshot-mcp.yeetful.com
Relay a user-signed EIP-712 vote envelope to the Snapshot sequencer. Requires the signature + the exact typed data from prepare_vote.