12 tools with complete schemas and descriptions, but quality is uneven. Tool names follow verb_noun convention well (create_project, get_deployment, list_projects). Descriptions are present but brief (avg ~60 chars, below 194-char baseline). Parameters have types and descriptions, but lack depth on constraints, formats, and dependencies. No output schemas documented. Error handling guidance absent. Security considerations (secrets, permissions) not visible in tool definitions.

• Document output schemas for all tools. E.g., get_project should return {project_id, slug, access, description, resources: {postgres, storage, llm}, created_at}. This enables LLM chaining.
• Expand descriptions to 100-200 chars. Add WHEN to use, prerequisites, and side effects. E.g., 'Create a project with isolated PostgreSQL database and object storage. Requires valid slug (2-50 chars, alphanumeric+dash). Returns project_id for use in subsequent calls.'
• Add error handling guidance to write tools. E.g., deploy_version: 'Returns 400 if build fails (check logs via get_deployment), 429 if quota exceeded (upgrade plan), 500 if infrastructure error (retry after 60s).'
• Specify parameter constraints in descriptions. E.g., slug: '2-50 lowercase alphanumeric and dash, must be unique', directory: 'absolute or relative path, must exist and contain valid project files'.
• Add tool annotations (destructiveHint, idempotentHint) to schema. E.g., deploy_version is destructive (replaces live version); set_project_secrets is idempotent (overwrites previous values).

Inferred effective spec: <=2025-11-25.

• Relies on Stateful initialize / Mcp-Session-Id (removed; protocol is stateless) - make each request self-contained