The MCP Orchestrator server has a single tool 'dynamic_downstream_tools' that is dynamically composed from downstream MCP servers. The tool itself has a generic, high-level description but lacks concrete input/output schema documentation visible in the source code. The tool is described as a meta-router that 'dynamically discovers and exposes all tools from downstream MCP servers' but the actual schema for how clients invoke this tool, what parameters it accepts, what it returns, is not evident in the provided source. The description is 173 characters, which is within the 10 - 1024 range, but it describes the router's internal behavior rather than the tool's external contract. No input schema is visible. Output structure is not documented. The tool name 'dynamic_downstream_tools' is also problematic, it is a noun phrase (tool discovery mechanism) rather than a verb-driven action name (e.g., 'call_downstream_tool', 'route_tool_call'). The description does not explain to an LLM when to call this tool, what parameters it expects, or how to interpret results.

• Rename the tool from 'dynamic_downstream_tools' to an action-verb name such as 'call_downstream_tool' or 'route_and_call_tool'. This helps LLMs immediately recognize the tool's purpose.
• Define explicit input parameters for the tool: tool_name (string, required), tool_arguments (object, optional), server_name (string, optional for namespaced calls), with descriptions explaining each.
• Document the output schema, including success/error cases. E.g., 'Returns { success: boolean, result: object, server_used?: string, error?: string }'.
• Rewrite the description to focus on the external contract: 'Calls a tool available in any connected downstream MCP server. Provide the tool name (optionally namespaced as 'server.tool-name') and arguments. The router automatically handles load balancing and fallback to redundant servers.'
• Document rate limiting and timeout behavior in the description: 'Rate limits and timeouts are applied per server and tool as configured in the orchestrator's config. Exceeded limits return a clear error with retry guidance.'
• Add parameter descriptions explaining namespace resolution: 'Use 'server.tool-name' for explicit routing, or 'tool-name' for unambiguous tools. Ambiguous names will fail with a list of matching options.'
• Ensure error responses include actionable guidance: 'Tool not found in any server. Available tools: [list]. Did you mean one of these?' rather than a bare 404.