Three well-structured READ_ONLY tools with clear naming, good descriptions, and complete input schemas. All tools follow verb_noun pattern (lookup, search, resolve). Descriptions are detailed and context-appropriate (71-152 chars, within the 10-1024 baseline). Input parameters have types and descriptions. However, output schemas are not explicitly documented in the source code, inference from type definitions is present but not schema declarations returned to clients. No error handling guidance, no recovery instructions, and no destructive/idempotent annotations. Protocol readiness is strong (HTTP transport), but definition completeness falls short of A-grade standards due to missing output schema documentation and error guidance.

• Add explicit output schema documentation to each tool definition. For lookup_legislator, document that it returns a Legislator object (or array) with fields: id, chamber, district, name, email, phone, phoneLabel, phoneTypeUnknown, session. Use the TypeScript types from packages/types/index.ts as the source of truth.
• Add error handling guidance to each tool description. Example for lookup_legislator: 'If legislator not found by name, try searching by district and chamber first. Returns empty array if no match.'
• Expand resolve_address parameter description to specify: 'Street address in Utah (format: number street name, city, state ZIP recommended). Resolves to house and senate district numbers.'
• Document the return structure for search_bills pagination explicitly. State: 'Returns bills array with total count. Use offset + count to implement pagination; when offset + count >= total, all results fetched.'
• Add readOnlyHint annotation to all three tool definitions to signal to clients that these are safe read-only operations with no side effects.
• For search_bills, document the FTS5 full-text search behavior (what fields are indexed, how query syntax works) so LLMs understand the power and limits of the 'query' parameter.