The server has 4 tools with varying quality. web_research has an excellent description (184 chars, actionable guidance on when/how to use), but its schema is minimal (single string param with basic description). obsidian_search, obsidian_read_note, and obsidian_traverse_relations have adequate descriptions but lack parameter depth and output schema documentation. All tools are read-only (low risk), but descriptions for Obsidian tools lack the LLM-optimization seen in web_research. No error handling guidance, no output schemas documented, no parameter constraints (enums, ranges, formats). Naming is clear and verb-forward (search, read, traverse), but parameter descriptions lack detail on format/constraints expected by downstream tools (e.g., what format is 'note_name'? Does it include .md extension? Is it case-sensitive?).

• Document output schemas for all tools. For web_research, specify: {success: boolean, answer: string, sources: [{url: string, title: string}]}. For obsidian_search: {notes: [{note_name: string, excerpt: string}], total: integer}. This enables LLM planning.
• Add parameter format guidance. 'note_name (string): The name of the note to read, e.g., "Project Planning" or "folder/subfolder/Note". Do not include .md extension.' Similarly, for 'relation_types', list valid options: "prerequisites", "components", "alternatives", "tooling", etc.
• Document bounds for numeric parameters. 'limit (integer, default 20, range 1 - 100): Maximum number of results. Higher values may timeout.' 'depth (integer, default 2, range 1 - 5): Maximum traversal depth to prevent infinite loops.'
• Add error recovery guidance to descriptions. E.g., 'obsidian_search: If no results match the query, try a broader search term or use obsidian_traverse_relations to explore related notes.' For obsidian_read_note: 'If the note is not found, call obsidian_search to verify the correct note name.'
• Ensure output field names match input parameter names across tools. If obsidian_search returns 'note_name' in results, obsidian_read_note must accept 'note_name' as a parameter (not 'name' or 'id'). This allows fluent tool composition.
• Add pagination to obsidian_search if it can return many results. Accept 'offset' or 'cursor' and return 'has_more' or 'next_cursor' in the response.
• Consider supporting natural identifiers in obsidian_read_note (e.g., both 'Project Planning' and 'projects/planning' formats) and document this in the description.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry