Three tools with clear naming (verb_noun pattern) and reasonable descriptions (100-150 chars each). All tools have input schemas with Zod validation. However, output schemas are undocumented, LLMs cannot predict response structure. Parameter descriptions are present but minimal (10-30 chars). Error handling returns structured ToolText with isError flag, but recovery guidance is sparse. No tool annotations (readOnlyHint/destructiveHint). terso_capture is a WRITE operation but lacks confirmation/dry-run pattern.

• Document output schema for each tool. Example: terso_search returns {content: [{type: 'text', text: string}], isError?: boolean}. Include field types and sample structure so LLMs can plan chaining.
• Add readOnlyHint and destructiveHint annotations to tool definitions. terso_get_context and terso_search: readOnlyHint=true. terso_capture: destructiveHint=true. Enables client-side safety filtering.
• Expand parameter descriptions to 50-100 chars with context. E.g., 'Search query (1+ chars), searches captured knowledge in Omnus. Use when you need project-specific info beyond AGENTS.md. Requires auth.'
• Implement dry-run or confirmation for terso_capture. Return a preview of what will be sent before committing. Document idempotency: 'Sending the same text twice creates one record, not duplicates.'
• Enhance error messages with actionable recovery steps. E.g., 'No Omnus API token. Set TERSO_API_TOKEN env var or run `terso auth set <token>`. Then retry.' instead of bare error text.