Server has 21 tools with consistent naming (verb_noun pattern) and reasonable descriptions (avg ~100 chars). Input schemas are present and use Zod validation with proper types. However, output schemas are not documented in the tool definitions, LLMs cannot see what fields to expect from responses. Parameter descriptions are adequate but lack format constraints (e.g., Ethereum address format '0x...' is mentioned in some but not all address params). Error handling is minimal, no recovery guidance or actionable error messages visible in tool code. Security is sound (no secrets in params, API key injected server-side). Composition is good: tools are single-responsibility and chainable (e.g., list_organizations → get_organization). Overall: solid foundation, but missing output documentation and error guidance that would push this to 70+.

• Document output schemas for all tools. Add a 'Returns' section to each tool definition showing field names, types, and descriptions. Example: 'Returns: { organizations: Organization[], pagination: { hasNextPage: boolean, totalCount: number } }'.
• Standardize address parameter documentation. Add a shared constraint: 'Ethereum address in 0x-prefixed hexadecimal format (e.g., 0x1234...abcd)' to all address parameters.
• Add error handling guidance to tool descriptions. Example: 'If organization not found, returns error with available organization slugs. Retry with suggested slug or call list_organizations() to discover valid IDs.'
• Restrict or document custom_query. Either remove it and wrap common queries in dedicated tools, or document allowed query patterns and add input validation to prevent injection attacks.
• Verify tool registration for get_voter_profile, get_delegation_status, get_vote_history. Ensure they are explicitly registered in the main tool handler, not just in test files.