This Bitbucket MCP server presents 24 tools with basic structure but significant quality gaps. Tool naming follows action-verb conventions (get_, create_, list_, etc.), which is correct. However, tool descriptions are uniformly terse (13-45 characters), falling well below the 50-200 character LLM-optimized baseline. Parameter descriptions exist for major identifiers (workspace, repo_slug, pr_id) but are generic and lack format/constraint details. Input schemas are present and typed (string, object) but lack enum constraints, minLength/maxLength bounds, or detailed format documentation. Output schemas are not visible in the provided code, the implementation delegates to reqwest::Client and returns resp.json() without documenting what fields agents should expect. Error handling is minimal: a generic HTTP error response with status and text, but no recovery guidance or categorization. The server does not implement parameter validation, does not document pagination cursor mechanics, and does not include per-item success/failure for batch operations. Tool composition is sound, each tool has one responsibility, but the interface is API-centric rather than agent-centric (e.g., requires workspace/repo_slug for every PR operation, forcing agents to look them up repeatedly). No tool exhibits the dependency hints, chaining-ID inclusion, or natural-identifier support that would make the agent workflow efficient.

• Expand all tool descriptions to 80-150 characters following the pattern: 'ACTION: what the tool does. USE WHEN: when/why to call it. RETURNS: what fields the agent gets.' Example: 'Create a bitbucket pull request. Use to propose code changes. Returns: pull_request_id, url, state, created_on.'
• Add explicit output schemas for all tools documenting the fields agents should expect (pr_id, workspace, repo_slug, state, created_on, author, etc.). This enables chaining and prevents wasteful lookup calls.
• Add limit, offset/page, and cursor parameters to all list_* tools with descriptions: 'Results per page (1-100, default 20). Fetch next results via the returned next_cursor.' Return a next_cursor or pagination token so agents can fetch more without guessing.
• Enhance input schemas for 'body' parameters (create_pullrequest, update_pullrequest, add_pullrequest_comment, add_pullrequest_task) with explicit required/optional fields and enum constraints. For example: { type: 'object', required: ['title', 'source'], properties: { title: { type: 'string', minLength: 1, maxLength: 255 }, source: { type: 'object', required: ['branch', 'repository'] } } }
• Implement input validation in the tool handlers and return actionable error messages. Example: 'Invalid pr_id: got "abc" (expected numeric). Valid PRs: 1, 2, 5. Try list_pullrequests(workspace="my-workspace", repo_slug="my-repo") to see available PRs.'
• Add error categorization and recovery guidance. Classify errors as 'retryable' (network timeout), 'user-fixable' (invalid workspace), or 'fatal' (auth failure). For 404 errors, return suggestions: 'Repository "my-repo" not found in workspace "my-ws". Available repos: proj-api, proj-web, proj-docs.'

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry