Three tools with clear verb-noun naming (search_chats, get_session, get_turn) and solid descriptions (avg 150 chars). All parameters have types and descriptions. However, output schemas are not documented in the source, only input schemas are visible. Error handling is absent: no guidance on what happens when a session_id is invalid, when FTS syntax fails, or when neighbors exceed bounds. Parameter descriptions lack format/constraint details (e.g., what format is session_id? 'codex:abc123' is shown as example but not formalized). No pagination guidance despite search_chats returning ranked results. Composition is sound, tools chain logically (search → get_session → get_turn). Security is appropriate for read-only operations.

• Document output schemas for all three tools. Specify what fields search_chats returns (e.g., title, source, model, when, snippet, provenance), what get_session returns (session header + turns array), and what get_turn returns (chunks + neighboring turns). Include field types and whether they are always present.
• Add error handling guidance to tool descriptions. E.g., 'If session_id is invalid, returns error with available session IDs. If raw_fts syntax is malformed, returns error with FTS5 syntax hints. If neighbors exceeds 10, returns error with valid range.'
• Formalize session_id and turn_id format constraints. Specify: 'session_id format: {source}:{id} where source is one of: codex, claude, copilot, gemini, cursor, opencode.' Add similar constraint for turn_id.
• Clarify raw_fts parameter with a concrete example. E.g., 'If true, treat query as raw SQLite FTS5 MATCH syntax (e.g., "python AND (bug OR error)"). If false (default), treat as natural language and convert to FTS5 internally.'
• Add total_results or next_cursor to search_chats response schema to enable pagination. Document: 'Results are ranked by relevance. If total_results > limit, use offset parameter (not yet exposed) or implement cursor-based pagination for large result sets.'