Critical gaps across all dimensions. Tools are dynamically loaded from remote Stitch API at startup via tools/list RPC, then wrapped as MCP tools. However, the source code shows NO explicit tool definitions with schemas or descriptions, only a generic wrapper that copies remote tool metadata. Input schemas are inferred from the remote API response but not visible in the MCP server code itself. Descriptions are copied from remote metadata (unknown quality). No parameter-level descriptions visible. Output schemas are not documented. Error handling is minimal, responses are formatted for display but lack recovery guidance. Security: GCP credentials are injected via environment (STITCH_GCP_PROJECT) and gcloud CLI, which is correct, but no per-tool permission gates or audit logging. Composition: tools are tightly coupled to the Stitch API; no abstraction or simplification for the LLM. Per-tool scores reflect the inability to verify schemas and descriptions in the MCP server code itself.

• Add explicit tool descriptions to the MCP server code. Do not rely on remote metadata. Each tool description should state WHAT it does, WHEN to use it, and any prerequisites (50-200 chars). Example: 'create_project: Create a new Stitch design project. Use this to start a new design system or UI component library. Returns project ID and title.'
• Document input schemas explicitly in the MCP server. For each tool, define parameter types, descriptions, and constraints. Example for list_design_systems: {"projectId": {"type": "string", "description": "The GCP project ID (e.g. my-project-123). Required."}}
• Document output schemas. Add a comment or docstring for each tool describing the response structure. Example: 'Returns {"projects": [{"name": string, "title": string, "id": string}], "total": int}'
• Wrap error responses with recovery guidance. Catch Stitch API errors and return actionable messages. Example: 'Project not found. Available projects: [list]. Try list_projects() to see all projects.'
• Add permission checks and audit logging. Gate destructive tools (create_*, edit_*, delete_*) behind permission validation. Log all tool calls with user ID, tool name, parameters, timestamp, and result to stderr or a logging service.

Inferred effective spec: 2025-06-18+.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry