Drama MCP exposes 43 tools with basic schemas and minimal descriptions. All tools have input schemas with required fields and type definitions, but descriptions are uniformly terse (10-30 chars), falling well below the 50-200 char LLM-optimized baseline. Parameter descriptions are entirely absent, only field names and types are visible. No output schemas are documented. Error handling is not evident in tool definitions. The server implements a thin adapter over a Drama plugin, delegating logic downstream, which limits visibility into validation, recovery guidance, and error classification. Tool naming follows verb_noun convention (create_work, get_script, list_episodes) but lacks context about when to use similar tools (e.g., search_works vs list_works distinction is unclear). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present despite clear WRITE vs READ_ONLY risk classifications in the metadata.

• Expand all tool descriptions to 50-200 characters. Example: 'Create a new work' → 'Create a new dramatic work (film, series, play). Returns work ID and metadata. Use before creating scripts.'
• Add descriptions to every parameter. Example: 'content' → 'Structured metadata object (JSON). Stores theme, format, arc, or other domain-specific fields. Optional.'
• Document output schemas for all tools. Specify which fields are returned (id, title, description, content, createdAt, etc.) and their types. Include chaining IDs (e.g., work.create_work should return work_id for use in script.create_script).
• Add tool annotations: mark WRITE tools with destructiveHint=true, READ_ONLY tools with readOnlyHint=true, and idempotent operations (get, list, search) with idempotentHint=true. This enables agents to reason about retry safety.
• Add error handling guidance to tool descriptions. Example: 'If media.import_media fails, check that source_ref is a valid URL and the media_type is supported (image, video, audio). Retry with a different source.'