This server exposes only a single tool, 'tool_invoke_handler', which is poorly defined for agent use. The tool name does not follow verb_noun convention (should be something like 'invoke_tool' or 'execute_tool'). The description is cryptic ('HTTP stream handler: forward request to corresponding QUIC tool with SSE response') and does not explain WHAT the tool does from an agent's perspective, WHEN to use it, or what parameters mean. The input schema declares three parameters (tool_name, body, headers) but none have meaningful descriptions beyond the cryptic 'Request body bytes' or generic 'HTTP headers'. The 'body' parameter accepts raw bytes with no guidance on format or expected structure. The 'headers' parameter is typed as 'object' with no schema definition for required/optional fields. There is no documented output schema. Error handling is absent, no guidance on retryable vs fatal failures, no recovery suggestions. The tool appears to be an internal implementation detail (a proxy handler) rather than a user-facing agent tool. This is a fundamental misunderstanding of MCP tool design.

• Rename tool to 'invoke_tool' or 'execute_tool' to follow verb_noun convention.
• Rewrite description to explain the business purpose: 'Invoke a registered QUIC-based tool by name. Use this to call any available tool in the serverless runtime. Returns response data or a streaming event stream if the tool produces chunked output.'
• Replace 'body' parameter description with actionable guidance: 'Request body as bytes. Format depends on the tool being invoked, provide JSON, plain text, or binary data as the target tool expects.'
• Add enum or constraint for 'tool_name': describe how to discover available tools (e.g., 'Call list_tools first to see valid names') or provide explicit enum list.
• Define 'headers' as an object with explicit properties: mark 'X-Trace-Id' and 'X-Span-Id' as optional, describe their purpose for tracing/observability, and document 'X-Extension' format.
• Document output schema explicitly: 'Returns either a JSON object (for byte responses) or a server-sent event stream (for chunked responses). On error, returns HTTP status code and error_msg field.'
• Add error handling guidance to description: 'If the tool name is invalid or the tool fails, returns an HTTP error status with a descriptive error message. Check the error_msg field for recovery guidance.'
• Consider whether this should be a single catch-all proxy tool or if specific tools should be registered individually with clear names and schemas. A catch-all proxy undermines LLM decision-making.

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

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