This HTTP server exposes 43 REST endpoints as MCP tools, but lacks critical MCP-compliant tool definitions. Tools are inferred from HTTP routes rather than explicitly registered with JSON Schema input/output definitions. Descriptions exist but are minimal (avg ~40 chars, mostly in Chinese). No input schemas are visible in the source, parameters are documented in prose descriptions only. No output schemas documented. Error handling returns generic HTTP status codes without recovery guidance. Tool naming uses HTTP verbs (GET/POST/PATCH/DELETE) rather than action verbs (get_, create_, update_). No tool annotations (readOnlyHint, destructiveHint, idempotentHint). This is a REST API wrapper, not a properly structured MCP server.

• Refactor tool definitions to use explicit MCP tool registration with JSON Schema. Replace HTTP route inference with formal tool objects: { name, description, inputSchema, outputSchema }.
• Rename all tools from HTTP verbs to action verbs: 'list_projects', 'create_project', 'update_project', 'delete_project', 'apply_project', 'rollback_project', etc. Follow verb_noun convention.
• Expand descriptions to 50-200 characters in English. Include: what the tool does, when to use it, prerequisites, and what it returns. Example: 'List all projects in the workspace. Returns project ID, name, path, and applied agents. Call this first to discover available projects.'
• Document output schemas for all tools. For list endpoints, include pagination (limit, offset, total_count). For object endpoints, specify all returned fields and their types.
• Add tool annotations: readOnlyHint=true for GET endpoints; destructiveHint=true for DELETE endpoints; idempotentHint=true for endpoints that can be safely retried (e.g., apply, rollback).