Critical gaps across all three tools. Tool definitions lack input parameter descriptions entirely, the schema shows parameter names and types but no descriptions explaining what each parameter controls. Tool descriptions are minimal (10-30 chars) and fail to explain WHEN to use each tool or WHAT it returns. No output schemas are documented. The 'call_tool' tool accepts arbitrary 'arguments' as an untyped object with no validation guidance. No error handling patterns are visible. These tools appear to be thin wrappers around a remote Unreal MCP server without proper LLM-facing documentation.

• Add 50-150 character descriptions to each tool explaining what it does, when to use it, and what it returns. Example: 'list_toolsets: Retrieve all available tools from the Unreal MCP server. Call this first to discover what tools are available before calling describe_toolset or call_tool.'
• Document the output schema for each tool. For list_toolsets, specify: returns array of {name: string, description: string}. For describe_toolset, specify what fields are in the toolset description. For call_tool, specify the response structure (success vs error).
• Add descriptions to 'call_tool' parameters: 'name' should explain it's the tool name from list_toolsets; 'arguments' should document the expected object structure or reference Unreal MCP documentation.
• Implement error handling that guides the LLM. If call_tool fails with 'tool not found', return 'Tool "X" not found. Available tools: [list]. Call list_toolsets() to refresh.' This enables self-correction.
• Consider splitting 'call_tool' into domain-specific tools (e.g., 'create_toolset', 'unreal_mcp_call') with explicit parameter schemas rather than a generic pass-through. This improves discoverability and reduces hallucination risk.

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

• Relies on Stateful initialize / Mcp-Session-Id (removed; protocol is stateless) - make each request self-contained