Bridge IDE MCP server has 16 tools with mixed quality. Most tools (tools 6-16) are READ_ONLY conversion/validation utilities with adequate schemas and descriptions. However, critical issues undermine production readiness: (1) Tool descriptions are often generic or lack actionable context (e.g., 'Convert MCP tool definitions to Anthropic Messages API format' lacks WHEN/WHY guidance). (2) Parameter descriptions are minimal, many lack format/constraint details. (3) No error handling guidance visible in any tool definition. (4) execute_tool accepts arbitrary kwargs with no validation schema shown. (5) register_tool accepts raw Python code (100KB max) with security implications not documented. (6) No output schemas documented for any tool. (7) Tool composition is weak, many conversion tools (mcp_to_anthropic, mcp_to_openai, etc.) duplicate logic rather than composing.

• Document output schemas for all 16 tools. Include field names, types, and descriptions. Example: list_tools should return {tools: [{name: string, description: string, schema: object}], count: number}.
• Enhance tool descriptions with WHEN/WHY context. For conversion tools, explain: 'Use mcp_to_anthropic when preparing tools for Claude API; mcp_to_openai for GPT models; mcp_to_gemini for Gemini models. Output format differs in parameter nesting and type representation.'
• Add parameter constraints and format guidance. For execute_tool.kwargs, document: 'Object with tool-specific parameters. Call get_tool(name) first to see required/optional params and their types.'
• Add error handling guidance to execute_tool, register_tool, delete_tool. Example: 'If tool not found, call list_tools() to see available tools. If execution times out (>300s), the tool may be hung, consider retrying with lower timeout.'
• Document security model for register_tool. Clarify: code is sandboxed/not sandboxed, what TOOL_META/TOOL_SCHEMA/execute() must contain, and audit trail for code registration.