OmniBrain has critical definition gaps across all 5 tools. Tool names lack action verbs (API-retrieve, API-get, API-post, API-query are prefixed with 'API-' which is non-standard). Descriptions are present but minimal (10-50 chars), below the 50-200 char LLM-optimized baseline. The two tools with schemas (API-retrieve-a-data-source, API-get-page-content) show only basic parameter definitions without type constraints, enums, or validation guidance. No output schemas documented. No error handling guidance. No parameter descriptions beyond the tool description itself.

• Rename tools to follow verb_noun convention: 'get_notion_database_schema', 'list_notion_users', 'search_notion_pages', 'get_notion_page_content', 'query_notion_database'. Remove 'API-' prefix.
• Expand descriptions to 50-200 characters. Include WHAT the tool does, WHEN to use it, and what it returns. Example: 'Retrieves all users in the Notion workspace. Use this to find user IDs before filtering pages by assignee. Returns array of user objects with id, name, email.'
• Add explicit input schemas for all 5 tools. For API-post-search and API-query-database, document all filter/sort parameters with types, enums, and constraints. Example: 'filters: {type: object, description: "Filter criteria (e.g. {property: \"Status\", value: \"Done\"})"}' with min/max bounds.
• Document output schemas for each tool. Specify which fields are returned, their types, and which IDs/references are needed for chaining. Example: 'Returns {id: string, name: string, email: string, workspace_id: string}' so downstream tools know what to expect.
• Add error handling guidance. For each tool, document common failures: 'If database not found, try search_notion_pages() first. If permission denied, verify Notion API token has read access.' Use pattern:recovery-guide.