BFB MCP server has well-structured tool definitions with consistent naming (verb_noun pattern), complete input schemas with type constraints, and clear parameter descriptions. All 7 tools follow the bfb_ prefix convention. However, tool descriptions are brief (avg ~60 chars, below the 194-char baseline), lack WHEN/WHY guidance, and output schemas are not documented. Error handling and recovery guidance are absent. Pagination is implemented (limit/cursor) but result limits are not stated in descriptions. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications in metadata.

• Expand tool descriptions to 100-200 chars. Add WHEN/WHY context: 'List all projects in your workspace. Call this first to discover available project IDs before creating tasks. Returns project metadata including ID, name, and access level.'
• Document output schemas for all tools. Specify returned fields, types, and which IDs are needed for chaining. E.g., 'Returns array of {project_id, name, access_level}. Use project_id with bfb_propose_task.'
• Add tool annotations via MCP schema: set readOnlyHint=true for list/get tools, destructiveHint=true for add_comment/propose_task (side effects), idempotentHint=true for tools accepting request_id.
• State pagination limits in descriptions: 'Returns up to 100 projects per page. Use cursor for pagination.' Include guidance on when to paginate (e.g., 'If you need all projects, iterate with cursor until null').
• Add error recovery guidance to descriptions. E.g., 'If task_id not found, call bfb_list_tasks to verify the ID exists. If request_id is reused, the operation is idempotent and safe to retry.'