mcp-proxy is a pass-through proxy server that dynamically exposes remote MCP server capabilities. Tool definitions are generated at runtime from remote server capabilities, not statically defined. All 10 tools have basic descriptions and parameter schemas, but descriptions are minimal (10-50 chars, well below the 194-char baseline). Parameter descriptions are sparse or missing entirely. No output schemas are documented. Error handling is absent, no recovery guidance or categorization. The server acts as a transparent relay, which limits its ability to provide LLM-optimized descriptions. Tools like 'call_tool' and 'complete' are generic pass-throughs with vague semantics.

• Expand tool descriptions to 100-200 chars. Example: 'list_prompts' → 'List all available prompts from the remote MCP server. Call this first to discover what prompts the server supports before requesting a specific one with get_prompt.'
• Add parameter descriptions for all inputs. Example: 'get_prompt.name' → 'The name of the prompt to retrieve (string, case-sensitive). Use list_prompts() to discover available names.'
• Document output schemas for each tool. Example: 'list_prompts returns {prompts: [{name: string, description: string, arguments: object}], ...}'. Include field types and meanings.
• Implement error handling with recovery guidance. Catch exceptions and return structured errors: {error: string, category: 'retryable'|'user_fixable'|'fatal', suggestion: string}. Example: 'Tool not found. Available tools: [...]'
• Add scope/permission declarations to 'call_tool'. Document what permissions the remote tool requires and whether the agent has authority to invoke it. Consider a 'confirm_before_execute' pattern for irreversible operations.

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

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