Server has 4 tools with complete schemas and descriptions. Naming follows verb_noun pattern (bb_list_endpoints, bb_request, bb_create_issue, bb_delete_issue). Descriptions are detailed and explain WHEN to use each tool. However, bb_request and bb_list_endpoints descriptions are verbose (300+ chars, exceeding the 200-char baseline for optimal LLM parsing). Parameter descriptions are present and mostly clear, but lack actionable error guidance. Output schemas are not documented, LLMs cannot predict response structure. Error handling is minimal; no recovery guidance provided. Tool composition is sound (single responsibility), but bb_request is a generic escape hatch that could mask missing domain-specific tools.

• Document output schemas for all tools. Example: 'bb_create_issue returns {issue_id: integer, key: string, url: string, created_at: ISO8601}'. This enables LLMs to chain tools and extract required fields.
• Trim bb_request and bb_list_endpoints descriptions to 150-200 chars. Move detailed guidance (paginate, raw, max_pages) into parameter descriptions instead.
• Add error handling guidance to each tool. Example: 'If workspace not found, call bb_list_endpoints with tag=Workspaces to discover valid workspaces.'
• Add a dry_run parameter to bb_delete_issue (and bb_request for DELETE methods). Return what would be deleted without executing, enabling agent confirmation.
• Clarify the 'raw' parameter in bb_request: 'Return response body verbatim (no JSON pretty-printing). Use for diff/patch/log endpoints that return text, not JSON.'