MCP Relay exposes 4 tools with basic schemas and descriptions. All tools have input schemas with typed parameters and descriptions present. However, descriptions are generic and lack actionable context for LLM selection. Tool naming follows verb_noun convention (discover, provision, execute) but lacks clarity on when to use each. Output schemas are not documented. Error handling guidance is absent. The server acts as a proxy/relay, which creates ambiguity: tools describe MCP relay operations, not domain-specific actions users would request in chat. This architectural choice limits the tool interface's alignment with the chat data model.

• Document output schemas for all tools. E.g. discover_tools returns {tools: [{tool_id: string, server: string, description: string, input_schema: object}], total: number}. This enables LLMs to extract tool_id for downstream execute_tool calls.
• Expand descriptions with WHEN and WHY. E.g. 'Discover relevant tools using semantic search. Call this first to find available tools matching a user query, then pass tool_id to execute_tool. Returns up to 10 tools ranked by relevance.'
• Add error handling guidance to execute_tool: 'If tool_id is not found, call discover_tools to search for the correct tool. If arguments are invalid, the error will specify required fields.'
• Clarify the 'arguments' parameter schema. Instead of generic object, document: 'Tool-specific arguments as a JSON object. The required fields depend on the tool_id, call discover_tools to see the input schema for each tool.'
• Consider wrapping the relay interface into domain-specific tools. Instead of expose discover_tools + execute_tool, offer tools like 'search_documents', 'send_email', 'create_ticket' that internally discover and execute the right backend MCP tool. This aligns the interface with user intent.

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

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