Server has 5 tools with basic schemas and descriptions, but significant gaps limit production readiness. All tools have descriptions (10-50 chars, mostly short), and input schemas are defined via Zod with types and enums. However, descriptions lack depth, they state WHAT but not WHEN or WHY. Parameter descriptions are minimal (e.g., 'The public ID of the asset' without format guidance). Output schemas are not documented; responses are JSON-stringified without field-level guidance. Error handling exists but lacks recovery hints. No tool annotations (readOnlyHint, destructiveHint). Tool naming is clear (verb_noun pattern), but composition could be tighter, delete-asset accepts two mutually exclusive params (publicId, assetId) without explicit guidance on precedence.

• Expand tool descriptions to 100-200 chars. Include WHEN to use, prerequisites, and what the response contains. E.g., 'Upload a file to Cloudinary. Accepts URLs, base64, or binary data. Returns asset metadata (public_id, url, resource_type). Use this before calling get-asset to retrieve details.'
• Document output schemas explicitly. For each tool, add a 'Returns' section listing field names, types, and meanings. E.g., 'get-asset returns {public_id: string, url: string, resource_type: enum, tags: string[], ...}'.
• Add tool annotations via MCP SDK. Mark delete-asset with destructiveHint=true, get-asset/find-assets/get-usage with readOnlyHint=true. This enables LLMs to reason about safety and retry logic.
• For delete-asset, clarify mutual exclusivity: 'Provide either publicId OR assetId (not both). If both are provided, publicId takes precedence.' Add this to both the tool description and parameter descriptions.
• Enhance error messages with recovery hints. E.g., 'Asset not found. Try find-assets(expression="public_id:*") to search for similar assets.' This guides LLMs toward self-correction.