krabs demonstrates solid fundamentals: all 10 tools have descriptions (avg 85 chars), input schemas with types, and clear verb-noun naming (schema_describe, account_get, api_key_create, etc.). Mutation tools include intent, idempotencyKey, and dryRun parameters, excellent safety primitives. However, output schemas are not documented in the source; parameter descriptions lack format constraints and range limits (e.g., 'name: 1-200 characters' stated in description but not in schema); error handling is generic (ApiClientError with code/message/hint/field) without recovery guidance; and no tool annotations (readOnlyHint, destructiveHint, idempotentHint) are visible. The schema_describe tool is a strong discovery pattern, but its output structure is not defined. Composition is clean, each tool has one responsibility, but responses are JSON-stringified text blocks rather than structured MCP output, limiting downstream tool chaining.

• Add minLength, maxLength, pattern, and enum constraints to JSON Schema for all parameters. Expose productKinds, pricingModels, billingCycles, productStatuses as enum arrays in tool schemas.
• Document output schemas for each tool. Define the structure of account, product, api_key, and list response objects with typed fields (id, name, status, createdAt, etc.).
• Implement tool annotations: mark read-only tools with readOnlyHint=true, destructive tools (api_key_revoke) with destructiveHint=true, and idempotent mutations with idempotentHint=true.
• Enhance error messages with recovery guidance. E.g., 'Product prd_xyz not found. Call product_list() to see available products or product_create() to add a new one.'
• Return structured MCP ToolResult objects with typed content blocks instead of JSON-stringified text. This enables LLMs to parse responses reliably and chain tools without parsing ambiguity.