Three tools with complete schemas and basic descriptions. All tools have proper input schemas with types and required fields. Descriptions are present but generic (avg 95 chars, below 194-char baseline). Parameters lack depth: no enums for constrained values, no format specifications, no range constraints. Output schemas undocumented. Error handling returns raw error text without recovery guidance. No tool annotations (readOnlyHint, etc.). Naming is clear and verb-based (search, list, get), following conventions. Missing: parameter-level descriptions for some fields, output schema documentation, actionable error messages.

• Document output schemas for all three tools. Example for obsidian_search: 'Returns array of {file_path: string, chunk_index: number, content: string, score: number}'. This enables LLMs to extract and chain results.
• Add range constraints to parameter descriptions. Update 'limit' descriptions: 'Maximum number of results to return (1 - 100, default: 5)' and '(1 - 500, default: 50)'. Validate server-side and return actionable errors: 'limit must be 1 - 100, got 150'.
• Enhance error messages with recovery hints. Instead of 'query must be a non-empty string', return 'query cannot be empty. Provide a natural language search term (e.g., "machine learning algorithms").'
• Add tool annotations to inputSchema. Mark all three tools with readOnlyHint: true in the tool definition to signal they are safe to retry and do not modify state.
• Implement cursor-based pagination for obsidian_list_files. Add 'cursor' parameter and return {files: [...], next_cursor: string | null, total: number} to support iterating large vaults.

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

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