Portoser MCP server exhibits severe definition quality gaps. Tool definitions appear to be inferred from frontend API client code (web/frontend/src/api/client.js) rather than explicitly registered in the MCP server implementation. Input/output schemas are not visible in the provided source code. Tool descriptions are present but minimal (10-60 characters), lacking the depth needed for LLM reasoning. No parameter descriptions are visible for any parameters. The server appears to be primarily a web service orchestration platform with a frontend client, not a properly-structured MCP server with canonical tool definitions. Critical issue: tools are defined in frontend JavaScript client code, not in the actual MCP server backend, raising questions about whether these are true MCP tool registrations or merely HTTP API endpoints being called by a UI.

• Locate and examine the actual MCP server backend code (likely in demo/main.py or web/backend/main.py) to verify how tools are registered. The evaluation is based on frontend client code, which is not canonical for MCP tool definitions.
• For each tool, add a comprehensive description (50-150 characters) answering: (1) What does it do? (2) When should it be called? (3) What does it return? Example: 'Create a new MCP tool with Python code. Use this to extend the tool registry. Returns the tool name and registration status.'
• Add descriptions to every parameter. Example: 'code' → 'Python function code implementing the tool. Must be valid Python syntax, with a function signature matching the tool contract. Will be executed in a sandboxed environment.'
• Make tool names consistent with verb_noun convention. 'createMCPTool' should be 'create_mcp_tool' (snake_case per MCP conventions).
• Add enumerated options for string parameters where applicable (e.g., if 'description' has length constraints, document them).
• For deleteMCPTool, add a dry_run parameter (default=false) and require explicit confirmation. Or implement a separate 'validate_tool_deletion' tool that must be called first.
• For createMCPTool and updateMCPTool, implement code validation: parse the code, check syntax, and return clear error messages if invalid. Never silently accept broken code.
• Add explicit error handling and recovery guidance. Example error response: 'Tool name already exists. Use replace_existing=true to overwrite, or choose a different name. Available names: <list>'.