Server has 16 tools with consistent naming (verb_noun pattern) and descriptions present for all. However, descriptions are often terse (20-80 chars), parameter descriptions are minimal or absent, and output schemas are not formally documented. Input schemas exist but lack detail, most parameters are simple strings without format constraints, enums, or validation guidance. Error handling is basic (string returns, no recovery guidance). Security is reasonable (path traversal prevention in _safe_filename), but no permission gates or audit logging. Composition is sound, tools are single-responsibility and chainable. Overall: functional but below production baseline for agent-facing tools.

• Add parameter descriptions to all tools. For 'content' params, specify: 'Markdown content for the [resource]. Do not include frontmatter.' For 'filename', add: 'Filename without path (e.g., interview_2024_01.md). Must end in .md.'
• Document output schemas explicitly. E.g., list_interviews returns [{file: string, date: string, participant: string, classification: string, recruited_via: string}]. Use JSON Schema in tool definitions.
• Enhance error messages with recovery guidance. Instead of 'Error: filename already exists', return 'Error: interview_2024_01.md already exists. Try a different filename or call list_interviews() to see existing files.'
• Add enum constraints to set_stage input schema: new_stage should be enum: ['0', '1', '2', '3', '4']. This prevents invalid values and self-documents the tool.
• Implement tool annotations in FastMCP. Mark read-only tools (get_*, list_*, query_*) with readOnlyHint=true and destructive tools (update_*, set_*, add_*) with destructiveHint=true. This enables safer agent planning.