Server has explicit tool definitions with schemas and descriptions, but quality is inconsistent. All 6 tools have names starting with action verbs (list_, get_, create_) and descriptions present. However, descriptions are generic (avg ~40 chars, well below the 194-char baseline for A+ tools). Parameter descriptions are minimal or absent for several tools. Output schemas are not documented, responses are JSON-stringified without field-level guidance. Error handling is basic (catch-all with error.message). No tool annotations (readOnlyHint/destructiveHint) despite clear read/write distinction. Missing pagination guidance for list tools despite accepting page parameters.

• Add structured output schema documentation to each tool. Example for bitbucket_list_repositories: 'Returns {repositories: [{id, name, slug, description, links}], pagelen, page, size, total}'. This enables LLMs to extract and chain data.
• Expand tool descriptions to 100-200 chars following the pattern: WHAT (action), WHEN (use case), WHAT IT RETURNS (key fields). Example: 'List all repositories in a Bitbucket workspace. Use this to discover available repos before fetching details. Returns paginated list with repo names, slugs, and links.'
• Add tool annotations: set readOnlyHint=true for all list/get tools; set destructiveHint=true for bitbucket_create_pull_request (or add confirmation pattern).
• Document pagination behavior in list tool descriptions: 'Results are paginated (default 20 per page). Pass page parameter to iterate. Returns total count for planning.'
• Implement structured error responses with recovery guidance. Example: 'Workspace not found. Try list_workspaces() to see available workspaces.' instead of raw error.message.