OCC exposes 30 tools with basic naming and descriptions, but critical gaps undermine production readiness. Most tools lack output schema documentation, LLMs cannot plan downstream calls or extract required fields. Parameter descriptions are present but often generic (e.g., 'Tool arguments as JSON' for mcp_call). No error handling guidance, no recovery patterns, and no security annotations. Tool names follow verb_noun convention (good), but composition is weak: mcp_call and sandbox_exec are dangerously broad; bash and write_file expose irreversible operations without confirmation patterns. Descriptions average ~80 chars, below the 194-char baseline for A+ tools. No evidence of idempotency guarantees, permission gates, or audit trails. This is a capable orchestrator, but the tool interface is not LLM-optimized.

• Document output schema for every tool. Include field names, types, and which fields are required for downstream chaining (e.g., http_fetch should return status_code, body, headers; web_search should return url, title, snippet, source).
• Add confirmation/dry-run patterns to irreversible tools. bash, write_file, email, and notify should support a 'dry_run' parameter or require explicit 'confirm=true' to prevent accidental data loss.
• Expand mcp_call and sandbox_exec descriptions to explain when to use them vs direct tools. E.g., 'Use mcp_call to invoke tools from other MCP servers when you need functionality not available locally. Provide the server name, tool name, and arguments as JSON.'
• Add error handling guidance to tool descriptions. E.g., 'If http_fetch fails with a timeout, retry with a longer timeout_ms. If it fails with 401, the URL may require authentication.'
• Annotate tools with readOnlyHint, destructiveHint, and idempotentHint in the schema. Mark bash, write_file, email, notify, and sandbox_exec as destructive. Mark read_file, http_fetch, and db_query as read-only.