13 tools with consistent verb_noun naming (obsidian_list_tabs, obsidian_new_tab, etc.). All tools have descriptions (avg ~80 chars, baseline 194). Input schemas present for all tools with proper type definitions. However, descriptions are terse and lack context on WHEN to use each tool, prerequisites, or recovery guidance. Parameter descriptions are minimal (e.g., 'Tab index (number), URL fragment (string), or null for first tab' repeated 11 times). No output schemas documented. Error handling is absent, no guidance on what to do if a tab is not found or a navigation fails. Security concerns: obsidian_evaluate exposes arbitrary JavaScript execution without sandboxing or permission gates.

• Document output schemas for all tools. E.g., obsidian_list_tabs should return [{index: number, id: string, title: string, url: string}]. obsidian_read_text should return {text: string, truncated: boolean, charCount: number}.
• Add error recovery guidance to tool descriptions. E.g., obsidian_click: 'If the selector does not match, call obsidian_find(selector) first to verify the element exists and get its exact selector.'
• Gate obsidian_evaluate behind a confirmation step or restrict it to read-only expressions. Add a description warning: 'Arbitrary JavaScript execution. Use only for safe, read-only queries. For mutations, use obsidian_click, obsidian_type, etc.'
• Expand tool descriptions to explain WHEN to use each tool and how it differs from similar ones. E.g., obsidian_read_text vs obsidian_evaluate: 'Use read_text for visible text content; use evaluate for computed properties or DOM queries.'
• Add idempotency notes to mutation tools. E.g., obsidian_click: 'Idempotent if the element is a toggle or button. Non-idempotent if it increments a counter or appends to a list. Verify the desired state after calling.'