Directory

Snapshot DAO (Free)

DataFREERoutes in chatBaseEthereum

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?
88/100Alinted 7/8/2026, 3:13:21 PM
Param schemas
91% · w25
Descriptions
100% · w20
Live probe
100% · w15
Planner test
67% · w30
Affordances
100% · w10
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

  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.
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 here
    via 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 here
    via 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_proposal
    via 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_votes
    via 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_space
    via 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_query
    via 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_vote
    via 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_vote
    via 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.