This MCP server has severe definition quality issues across all dimensions. Of 10 tools, 6 are HTTP handler functions (mcp_handler, mcp_handler_domain, mcp_sse_handler, mcp_sse_handler_domain, mcp_http_sse_messages_handler, mcp_http_sse_messages_handler_domain) that appear to be internal routing/transport handlers rather than legitimate user-facing tools. The 4 demo tools (demo/search, demo/a, demo/b, demo/ping) are defined only in test files (tool_schema_extraction.rs), not in production code, indicating they are test fixtures. Critically: (1) Parameter descriptions are almost entirely missing across all tools; (2) Return/output schemas are completely undocumented; (3) Tool descriptions are minimal or generic ('MCP desc' for demo/ping, none for demo/a and demo/b); (4) No evidence of error handling patterns or recovery guidance; (5) The HTTP handlers expose internal routing parameters (org_slug, env_name, service) as tool inputs, which violates the principle that tools should expose user-facing intent, not API plumbing; (6) No idempotency or confirmation patterns for WRITE tools (mcp_handler, mcp_handler_domain, mcp_http_sse_messages_handler, mcp_http_sse_messages_handler_domain). The server conflates transport routing with tool definitions, these handler functions should not be exposed as tools at all; they are implementation details of the MCP transport layer.

• Remove all HTTP handler functions (mcp_handler*, mcp_sse_handler*, mcp_http_sse_messages_handler*) from the tool registry. These are internal transport routing functions, not domain tools. Tools should expose user-facing intent (e.g., invoke_language_runtime, execute_hot_function), not HTTP plumbing.
• Replace test-only demo tools with real, production-quality tools that exercise the Hot language runtime. Move tool definitions from test files into the main crate with proper MCP registration.
• Rename demo/a and demo/b to action-verb names that describe what they do (e.g., compute_a, calculate_b, or better yet, meaningful domain names like transform_data, validate_schema).
• Add comprehensive parameter descriptions to every tool. For demo/search: describe what the query accepts (free text, keywords, regex?), what 'limit' bounds are (1 - 100?), what the default is. For mcp_handler variants: document what org_slug, env_name, service control (or remove them and use config/context instead).
• Document output schemas for all tools. Include example responses, field types, and nested structure. LLMs cannot compose tools without knowing what fields they return.
• Add error handling guidance to tool descriptions. E.g., 'If search returns zero results, suggest a broader query or call list_available_docs to discover index contents.' Per pattern:recovery-guide.
• For WRITE tools, add idempotent hints or confirm-before-execute patterns. Document whether repeated calls with same params are safe or destructive. Per pattern:idempotent-operation, agents need to know if they can retry safely.