Storyplotter-MCP has well-structured tool definitions with consistent naming (verb_noun pattern) and complete input schemas. All 11 tools have descriptions and typed parameters. However, descriptions are brief (avg ~60 chars, below the 194-char baseline), parameter descriptions lack depth, and output schemas are not documented. Error handling is present but generic. No tool annotations (readOnlyHint/destructiveHint). The codebase shows solid engineering (comprehensive tests, proper validation), but tool definitions prioritize brevity over LLM-optimized clarity.

• Document output schemas for all tools. E.g., list_plots returns [{title, status, folder, tags, character_count, location_count}, ...]. This enables LLMs to chain calls correctly.
• Expand tool descriptions to 100-200 chars. Add context: 'List all plots in the user's library. Use this to discover available stories before calling get_plot for details. Supports filtering by status (writing/written), folder path, or tag. Returns up to 50 plots; use pagination for more.'
• Add tool annotations: mark all list_* and get_* tools with readOnlyHint=true; mark import_data with destructiveHint=true and idempotentHint=false (since overwrite=false prevents re-import).
• Replace example values with enums in parameter descriptions. E.g., status: 'One of: writing, written, archived' instead of 'e.g., writing, written'. Add enum constraint to schema if not present.
• Enhance error messages with recovery guidance. E.g., 'User not found. Ensure you are authenticated and have imported data via import_data.' or 'Invalid JSON in content parameter. Verify the export file is valid StoryPlotter JSON.'