The server defines 3 tools with explicit registrations in src/index.ts. All tools have names following verb_noun convention (deploy_to_shiped, list_shiped_projects, delete_shiped_project) and descriptions between 34 - 194 chars, which is within the 10 - 1024 baseline. However, parameter descriptions are inconsistent: deploy_to_shiped has detailed parameter documentation in the hardcoded schema (name, type, html, files all described), but list_shiped_projects and delete_shiped_project have minimal descriptions. Output schemas are NOT documented anywhere, there is no specification of what fields are returned by deploy_to_shiped (does it return url, deployId, status?), list_shiped_projects (structure of projects array?), or delete_shiped_project (success indicator?). Error handling is present (401 auth hint, deploy failure messages, polling with timeout) but does not follow the recovery-guide pattern, errors do not always tell the LLM what to do next. The oneOf constraint on deploy_to_shiped (html XOR files) is correctly expressed in JSON Schema but not mentioned in the description, which could cause LLMs to pass both. Security is strong: API keys are injected via env var and device-flow OAuth, never exposed as parameters. No credentials in tool signatures. Composition is good: three separate tools with clear responsibilities (deploy, list, delete) rather than combined operations.

• Document output schemas for all three tools. For deploy_to_shiped, specify: { url: string, deployId: string, status: 'deployed'|'installing', ... }. For list_shiped_projects, specify: { projects: [ { name: string, slug: string, url: string, type: string, createdAt: ISO8601 } ], total: number }. For delete_shiped_project, specify: { success: boolean, message: string }.
• Add pagination support to list_shiped_projects: accept limit (1 - 100, default 20) and offset/cursor parameters, and return a total count or next_cursor. Document this in the tool description.
• Revise deploy_to_shiped description to include: 'Pass either html (single file) or files (multiple files), but not both. Type defaults to static; use node or python for executable environments.' This makes the oneOf constraint explicit.
• Enhance error messages with recovery guidance. Instead of 'Deploy failed: Invalid project name', return 'Invalid project name. Project names must be 2 - 30 alphanumeric characters. Try: my-app, my_app, or MyApp.' This enables the LLM to self-correct.
• Add a destructiveHint annotation to delete_shiped_project (if using tool-annotations pattern) or state in the description: 'WARNING: This operation is irreversible. Once deleted, the project and its URL are permanently removed.' This signals to LLMs that deletion requires care.
• For deploy_to_shiped, document what happens during the 'installing' state and how polling works. Example: 'If status is installing, the tool automatically polls every 2 seconds up to 120 seconds. If it times out, the deployment may still succeed, check list_shiped_projects later.'