Two well-defined tools with clear naming (verb_noun pattern), comprehensive descriptions (194 - 250 chars), and complete input schemas using Zod with type constraints and parameter descriptions. Output is structured and actionable. Error handling is present but generic. No tool annotations (readOnlyHint/destructiveHint). Naming is clear and unambiguous; both tools follow single-responsibility principle. Descriptions explain WHAT, WHEN, and WHAT IS RETURNED. Parameters are typed and constrained (enums for format). However, output schema is documented only in prose (describeDiagram function), not as a formal JSON Schema. Error messages are user-friendly but lack recovery guidance (e.g., 'API key rejected' suggests checking DRAFT1_API_KEY, which is good, but no fallback options offered).

• Add tool annotations: mark both tools with destructiveHint: true (they modify state). This signals to agents that retries must be idempotent or confirmed.
• Document output schema formally. Define a Diagram response type with fields: id (string), shareUrl (string), pngUrl (string|null), xml (string), elementCount (number), sizeKb (number). Return this as structured JSON, not prose.
• Enhance error messages with recovery paths. E.g., 'API key rejected (401). Verify DRAFT1_API_KEY environment variable is set. Create a new key at https://app.draft1.ai/account/settings.'
• Add maxLength constraint to prompt parameter (e.g., 50000 chars) and document expected formats: 'Plain English description (e.g., "web app with load balancer") or raw source code (Terraform, docker-compose, Kubernetes YAML, SQL, Mermaid, PlantUML).'
• Consider offering a summary-only mode (e.g., format: 'summary' | 'full') to reduce token cost for large diagrams. Document in description: 'Set format="summary" to receive only diagram_id and shareUrl, omitting XML and PNG URL.'