MCP Observatory exposes only 1 tool: 'tools/call'. The tool definition is inferred from UI code (ToolInvoker.tsx), not from explicit server-side registration visible in the Rust crates. The input schema shows only 'name' (string) and 'arguments' (object) with minimal descriptions. No output schema is documented. The tool description is generic ('Invokes a tool on an upstream MCP server') and lacks guidance on when/why to use it, error recovery, or what fields the response contains. This is a proxy/observatory tool, not a domain-specific tool suite, which limits applicability of standard tool patterns. However, even for a proxy, the schema and descriptions are severely underdeveloped.

• Add explicit tool registration in Rust server code (mcpobs-server crate) with full JSON Schema for input and output. Do not rely on UI inference.
• Document the output schema: what fields does the response contain? (e.g., result, error, status, execution_time). Include types and descriptions for each field.
• Expand tool description to 100-200 characters: explain that this tool proxies calls to upstream MCP servers, when to use it (e.g., for observability/debugging), and what happens on upstream failure.
• Replace 'arguments: object' with a proper schema that describes the expected structure. If arguments are tool-specific, document that the schema depends on the upstream tool's input schema.
• Add error handling documentation: describe how errors from upstream tools are surfaced, whether calls are retryable, and what the LLM should do if invocation fails.