Things MCP has solid naming conventions (verb_noun pattern across all 28 tools) and comprehensive parameter schemas with types and descriptions. However, tool descriptions are inconsistent in depth, some are terse (e.g., 'Get all areas' for get_areas), falling below the 50-200 char LLM-optimized baseline. Output schemas are not documented in the source code provided, forcing LLMs to infer response structure. Error handling is minimal; no recovery guidance or actionable error messages visible. Security is reasonable (no exposed credentials), but composition could be tighter, some tools overlap in intent (e.g., search_todos vs search_advanced).

• Document output schemas for all tools. For each tool, specify the JSON structure returned: field names, types, and what each field represents. Example: get_inbox returns {todos: [{id: string, title: string, notes: string, tags: string[], deadline: string|null}], count: number}.
• Expand terse descriptions to 50-200 characters. Replace 'Get all areas' with 'Retrieve all areas in your Things library. Use this to discover available areas before filtering todos or creating projects in a specific area.' This guides LLM selection and explains when to call the tool.
• Add error handling guidance to write tools. Document what can fail (e.g., 'Invalid tag name: tag must exist or be created first') and what the LLM should do (e.g., 'Call get_tags() first to see available tags, or create a new tag via add_todo with a new tag name').
• Consolidate search_todos and search_advanced into a single search_todos tool with optional filter parameters (status, tag, area, project, type, created_within_days). This reduces cognitive load on LLMs and eliminates duplicate tool selection logic.
• Add pagination support to list tools. Tools like get_todos, get_projects, get_logbook should accept limit and offset/cursor parameters and return a total_count field. This prevents context window exhaustion when users have large libraries.