Tool Compass demonstrates solid definition quality across 19 tools with consistent naming, reasonable descriptions, and complete input schemas. All tools follow verb-noun patterns (search_, list_, get_, create_, update_, delete_, archive_, restore_, prepare_, reindex_, generate_). Descriptions are present and contextual (average ~80-120 chars), explaining WHAT the tool does and its domain (Bridge content management, semantic search, project/session orchestration). Input schemas are fully specified with types and parameter descriptions. However, there are systematic gaps: (1) NO output schemas documented anywhere, LLMs cannot infer what fields these tools return, preventing composition and forcing discovery via trial-and-error; (2) descriptions lack WHEN/WHY guidance (when should an agent call semantic_search vs search_bridge?); (3) no error handling guidance (what happens if a project_id is invalid? Can the agent recover?); (4) no pagination parameters on list tools (list_projects, list_sessions); (5) no parameter validation hints (e.g., content_type enum values, or checkpoint name constraints); (6) semantic_search and search_bridge both exist with minimal differentiation in descriptions, risking LLM confusion. Parameter descriptions are terse but present. Risk classifications (READ_ONLY, WRITE, DESTRUCTIVE, REVERSIBLE) are clearly marked, aiding security modeling. Overall: strong foundation, but missing the refinements that separate B-tier from A-tier tool definitions.

• Document output schemas for all tools. Example: bridge:get_project_summary should document: { id: string, name: string, items_count: number, created_at: ISO8601, recent_items: [{id, title, created_at}, ...] }. This enables LLMs to know what fields are available for downstream tool calls.
• Add WHEN/WHY guidance to search_bridge vs semantic_search descriptions. E.g., 'Use search_bridge for keyword/phrase matching on exact terms or metadata. Use semantic_search for conceptual similarity and AI-powered relevance ranking.' Similarly, clarify archive_project (soft delete) vs delete_bridge_content (hard delete) distinction.
• Add pagination to list_projects and list_sessions. Signatures: list_projects(include_archived?, limit=20, offset=0) returning {projects: [...], total_count, has_next}. Prevents context window overflow and enables multi-page traversal.
• Add error handling patterns to write/destructive tools. Descriptions should note: 'Returns 400 if project_id not found (try list_projects first). Returns 409 if session already exists (try get_session to check). Returns 500 on database error (retryable).' Enable LLM recovery and reduces retry loops.
• Specify content_type enum values. E.g., 'content_type: one of ["text", "markdown", "json", "html"] (default: "text")' in add_bridge_content. Add max length constraints for title and content parameters.
• Add dry-run parameter to delete_bridge_content. E.g., delete_bridge_content(content_id, dry_run=true) returns what would be deleted without executing. Prevents accidental destruction and aligns with pattern:confirmation-request.