This Knesset Data API MCP server demonstrates solid engineering with well-structured tool definitions, comprehensive parameter schemas, and thoughtful descriptions. All 12 tools are clearly registered with input schemas and descriptions. The naming convention is consistent (verb_noun: search_*, get_*), and parameter descriptions are generally detailed. However, output schemas are not explicitly documented in the source code (only inferred from return types), and error handling lacks recovery guidance. The server uses fastmcp with Streamable HTTP transport and stateless mode, showing good protocol awareness. Pagination is properly supported across search tools with page/page_size parameters. Main gaps: (1) output schemas not formally specified in tool definitions, (2) no tool annotations (readOnlyHint/destructiveHint), (3) error responses likely lack actionable recovery guidance, (4) no documented dependency hints between related tools.

• Document output schemas for all tools. For each tool, specify the exact structure returned (e.g., search_bills returns {bills: [{id, name, status, initiators, dates}], total_count, next_page}). Include field descriptions so LLMs know what to extract.
• Add tool annotations to all 12 tools. Set readOnlyHint=true since all tools are safe read operations. This requires fastmcp v1.27+ but enables LLM safety reasoning. Example: @mcp.tool(name='search_bills', annotations={readOnlyHint: true}).
• Add actionable error messages. When a bill_id is not found, return 'Bill not found. Try search_bills() with a partial name or recent dates to discover the correct ID.' instead of a bare 404.
• Enhance tool descriptions with dependency hints. For search_* tools, add: 'Call this first to discover entities, then pass the ID to get_*_details() for full information.' For search_across, note: 'Use this for broad cross-entity search; use individual search_* tools for precise filtering.'
• Formalize enum constraints in tool parameters. Instead of status: {type: 'string', description: 'Bill status'}, use status: {type: 'string', enum: ['proposed', 'in_committee', 'passed', ...]} (derive from enum_sql at startup or hardcode known values).
• Consider adding pagination examples in descriptions. E.g., 'Results are paginated (default page_size=20). Call again with page=2 to fetch the next batch.' This reminds LLMs to handle large result sets.
• Add a result limit note. E.g., 'search_bills returns up to 100 results per page. If more exist, use pagination.' This prevents context window exhaustion if LLMs request very large page sizes.

Inferred effective spec: 2026-07-28+.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry