MCP Inspector exposes 8 tools with clear verb-noun naming (listTools, callTool, readResource, etc.). All tools have descriptions (avg ~60 chars, baseline 194 chars). Input schemas are present and typed for all tools. However, descriptions are significantly shorter than production baselines and lack context on WHEN to use each tool or what downstream actions they enable. Parameter descriptions are minimal (e.g., 'Arguments to pass to the tool' for callTool.args is generic). No output schemas documented. Error handling is basic, no recovery guidance or actionable error messages visible in the code. The server is a meta-tool for inspecting other MCP servers, which limits the need for complex composition, but descriptions should still guide LLM selection and explain dependencies.

• Expand tool descriptions to 100 - 200 characters. Include WHEN to use (e.g., 'Call this first to discover available tools before invoking callTool'), WHAT it returns (e.g., 'Returns a list of tool names, descriptions, and input schemas'), and any prerequisites.
• Add detailed parameter descriptions. For callTool.args, explain: 'A JSON object with tool-specific parameters. Structure depends on the tool's inputSchema (retrieved via listTools). Example: {"query": "search term", "limit": 10}.'
• Document output schemas for all tools. E.g., listTools returns {tools: [{name: string, description: string, inputSchema: object}]}. This enables LLMs to extract tool names and chain to callTool.
• Convert setLoggingLevel.level to an enum constraint in the schema: {"type": "string", "enum": ["debug", "info", "notice", "warning", "error", "alert", "emergency"]}. Remove the text list from the description.
• Add error recovery guidance. E.g., 'If callTool fails with "tool not found", call listTools() to verify the tool name. If it fails with "invalid arguments", check the tool's inputSchema for required fields and types.'

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

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