Loading ToolBench
MCP server for querying and analyzing DAO proposals from Snapshot
DAO Proposals MCP exhibits significant quality gaps across multiple dimensions. All three tools have descriptions and parameters are visible in the code, but the output schemas are undocumented (free-text string returns), parameter descriptions lack constraint information, and error handling provides no recovery guidance. Tool naming follows verb-noun convention (list_, get_) appropriately, but parameter descriptions are minimal. The server returns unstructured string concatenations rather than structured JSON objects, forcing LLMs to parse prose. No pagination support despite list_spaces returning only 10 items hardcoded. Error handling is generic ('Error: {str(e)}') with no actionable guidance for LLM retry logic. The server lacks modern MCP features like tool annotations, error reporting, and structured output.
Fetch detailed information for a specific proposal.
Fetch a list of recent proposals for a given Snapshot space.
Fetch a list of available Snapshot spaces.
Output schemas completely undocumented. All three tools return plain strings (unstructured text concatenation) with no documented schema. LLMs cannot understand what fields to extract or how to chain results to downstream tools.
Parameter descriptions lack constraint information. 'space_id' described as 'The unique identifier of the Snapshot space (e.g., 'ens.eth')' includes an example value, which LLMs may reuse literally. Missing format/validation guidance.
Generic error handling with no recovery guidance. Exceptions caught as 'Error: {str(e)}' provide no actionable next steps for the LLM (e.g., 'API unavailable, retry after 60s' or 'Invalid space_id, call list_spaces() first').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 42 | 2026-07-28+ | v2 |
No pagination support. list_spaces hardcodes first: 10 with no limit/offset parameters or next_cursor. Large result sets will blow context windows; LLMs cannot fetch additional pages.
Unstructured text output wastes tokens and invites parsing errors. All responses concatenate fields as prose ('Space ID: ...\nName: ...\n---') instead of returning structured JSON. LLMs must use regex/string parsing to extract data.
Tool descriptions lack clarity on when to use each tool. 'list_proposals' and 'list_spaces' don't explain the relationship (are spaces DAO groups? governance containers?). LLMs cannot infer the correct tool ordering.
No idempotence or dry-run support. These are read-only tools, so idempotence is present, but descriptions do not declare this explicitly. Agents cannot confidently retry without documentation.