MCP Inspector exposes 2 tools for introspection and tool invocation. Both tools have descriptions and basic input schemas, but lack depth in parameter documentation and output schema specification. listTools has a generic description (34 chars, below the 50-char baseline for discovery tools). callTool's schema documents 'name' and 'args' but provides no guidance on expected output structure, error cases, or how to handle tool failures. Neither tool includes parameter constraints (enums, ranges, formats) or recovery guidance. The 'args' parameter is a free-form object with no schema validation hints, inviting hallucinated payloads. No tool annotations (readOnlyHint/destructiveHint) are present despite callTool being a WRITE operation. Error handling is absent, no guidance on what happens when a tool call fails or times out.

• Add output schema to callTool: document that it returns {success: boolean, result?: any, error?: string, toolName: string}. Include examples of success and failure responses.
• Expand callTool description to 100-150 chars: 'Invoke a tool on the connected MCP server. Pass the tool name and arguments. Returns the tool result or error. Use listTools first to discover available tools.'
• Add parameter descriptions: 'name' → 'The exact name of the tool to invoke (case-sensitive). Call listTools to see available names.' 'args' → 'Object containing tool arguments. Structure depends on the tool, refer to listTools output for parameter schemas.'
• Add destructiveHint annotation to callTool since it can invoke write/delete operations. Document that some tools may have irreversible side effects.
• Document error cases: 'Tool not found', 'Invalid arguments', 'Tool execution timeout', 'Tool returned error'. Provide recovery guidance for each (e.g., 'Call listTools to verify the tool name').

Inferred effective spec: 2025-06-18+.

• Relies on Sampling (deprecated) - integrate directly with the LLM provider API