The Bear MCP server exposes three read-only tools for querying notes from a local SQLite database. While the tool names follow verb-first convention (get_*, search-like), the implementation has critical gaps in schema completeness, parameter descriptions, output documentation, and error handling. All three tools have input schemas defined in the ListToolsRequest handler, but parameter descriptions are minimal or missing, output types are undocumented, and error guidance is absent. The descriptions themselves are terse (10-47 chars) and lack context about when to use each tool or what they return. Most critically, the `getNotesLike` function contains a SQL injection vulnerability due to unparameterized string interpolation in the WHERE clause, which is a security and stability risk. No tool declares what it returns, no pagination is offered despite potentially returning hundreds of notes, and error paths do not guide recovery.

• Fix SQL injection: use parameterized queries. Replace `db.each('SELECT * FROM ZSFNOTE WHERE ... ZTEXT LIKE ?', [like], ...)` to prevent malicious input from modifying query logic.
• Add output schema documentation to ListToolsRequest. Each tool should declare: 'Returns array of objects: {title: string, subtitle: string, text: string, created_at: ISO8601, id: string}'.
• Expand tool descriptions to 150 - 250 chars. Example for get_notes_like: 'Search notes by keyword. Returns all non-archived notes whose title or body contains the search term. Returns up to 50 results; use pagination for more. Useful for finding related notes before creating a new one.'
• Add limit and offset parameters to get_notes and get_notes_like. Implement pagination: 'Returns up to {limit} results (default 20, max 100). Pass offset to fetch the next page. Include total_count in response.'
• Add error handling that returns structured errors with recovery hints. Example: if the database is locked, return {error: 'Database is busy. Retry in a few seconds.' retry: true}. If no results found, suggest 'No notes found. Try search_notes_like() with a broader term or check note tags with get_tags().'
• Document the `like` parameter fully: 'Case-insensitive substring search. Special characters (%, _) are treated literally. Max 256 chars.'
• Consider adding a `get_note_by_id` tool to fetch a specific note by ZUNIQUEIDENTIFIER, enabling two-step workflows: search → detail fetch.
• Add structured output in CallToolRequest responses. Instead of raw {toolResult: {notes: [...]}}, return {type: 'success', data: {notes: [...], total: N, has_more: bool}}. This signals to LLMs what to expect.