Two tools with basic Zod schemas and German descriptions. format_note has a clear verb-noun name and acceptable description (95 chars). save_note_to_obsidian is compound (save + format), violating single-responsibility. Both tools lack output schema documentation, LLMs cannot predict return structure. Parameter descriptions are present but minimal (10-40 chars), below the 72-char baseline. No error handling guidance, no recovery paths, no validation rules stated in descriptions. Schemas are present but sparse: raw is required string, isoDate/subfolder/useRest are optional with minimal constraint documentation. No enum constraints, no format specifications, no range limits. The code shows environment variable injection (SMART_NOTE_VAULT, OBSIDIAN_REST_URL) but no documentation of these prerequisites in tool descriptions. Overall: functional but well below production baseline.

• Split save_note_to_obsidian into two tools: save_note_to_vault (filesystem) and save_note_via_rest (Obsidian REST API). Each should have a single, clear responsibility.
• Add explicit output schema documentation: 'Returns {content: [{type: "text", text: string}]} where text contains formatted Markdown with YAML frontmatter.' Include example structure.
• Expand parameter descriptions to 50-150 chars with format/constraint details. E.g., 'isoDate: Optional ISO 8601 date (YYYY-MM-DD) for note metadata and filename. If omitted, uses current date.' Add dependency hints: 'Required if you need a specific date; otherwise auto-generated.'
• Document environment prerequisites in tool descriptions. E.g., 'Requires SMART_NOTE_VAULT env var (absolute path to Obsidian vault root) or OBSIDIAN_REST_URL + OBSIDIAN_REST_API_KEY for REST mode. See setup guide.'
• Add error recovery guidance: 'If SMART_NOTE_VAULT is not set, set the environment variable and retry. For REST mode, verify OBSIDIAN_REST_URL is reachable and OBSIDIAN_REST_API_KEY is valid.'