Two tools with minimal documentation. list_tools_handler has a basic description but no input schema (trivial, no params). call_tool_handler has a description and visible input schema with tool_name and arguments, but both descriptions lack depth on WHEN to use, error recovery, and prerequisites. No parameter descriptions beyond the schema. No output schema documented. No error handling guidance. Descriptions are 80 - 150 chars, below the 194-char baseline for production tools. No tool annotations (readOnlyHint, destructiveHint). Tool names lack verb clarity: 'list_tools_handler' and 'call_tool_handler' are implementation-focused, not user-intent-focused.

• Rename tools to user-intent names: 'list_tools' (not 'list_tools_handler') and 'call_tool' (not 'call_tool_handler'). Remove implementation jargon.
• Add output schema documentation. list_tools should document it returns a list of Tool objects with name, description, inputSchema fields. call_tool should document it returns CallToolResult with content (array of TextContent/ImageContent/etc) and isError flag.
• Expand call_tool_handler description to 150 - 250 chars explaining: (1) what it does (proxies calls to upstream MCP server), (2) when to use it (after list_tools to discover available tools), (3) error cases (policy blocks, timeout, upstream failure) and recovery hints.
• Add field-level descriptions to 'arguments' parameter. E.g., 'arguments: object with tool-specific key-value pairs. Keys and types depend on the tool selected; call list_tools first to see available tools and their input schemas.'
• Add tool annotations: mark call_tool_handler with destructiveHint=true (it proxies arbitrary tool calls, some destructive) and readOnlyHint=false. Mark list_tools_handler with readOnlyHint=true.

Inferred effective spec: <=2025-11-25.

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