It's a Thursday, and you have a failing build, a Jira item that explains why the change matters, and a Confluence page with the rollout plan. You'd like an AI assistant to look at all three without you pasting logs between tabs. Until now, connecting Bitbucket Cloud to that assistant meant working with API tokens. This week it gets simpler.
Atlassian has made Bitbucket Cloud easier for an AI assistant to reach. In its post, Connect Bitbucket Cloud to your AI tools with Atlassian MCP, the company explains that Bitbucket was already available through the Atlassian MCP Server with API tokens. The latest release adds OAuth, so you can sign in with your Atlassian account instead. In Atlassian's words: "API tokens remain supported, while OAuth offers a simpler way to get started with compatible AI clients."
The pitch is that one connection carries both halves of a change. "Jira explains why the change is needed, Confluence captures technical decisions and rollout plans, and Bitbucket provides the code, commits, pull request discussion, and pipeline results." The post gives no figures, but its examples are the right ones for your Thursday. An assistant can read a Jira item and its linked design page, implement the change and raise a pull request. Or, given a failing build, it can read the failed step and its logs, suggest a cause and raise a separate pull request with the fix.
The release also widens what the assistant can do inside Bitbucket. It can manage pull request comments and reviewer updates, find commits and locate related pull requests, so it can "help with implementation and review, not just retrieve information." That matters to you because access "remains governed by your existing Atlassian and Bitbucket permissions." The assistant sees what you see, no more.
There's one practical catch if you already use the older connection. OAuth arrives on a v2 endpoint, and v1 users may need to remove and re-add their connector.
Now the part where APIs.io looks at its own record. The catalog holds the Bitbucket surface in depth. The Atlassian provider page lists 186 API pages, and the two workflows above run over the Atlassian Pull Requests API, the Atlassian Bitbucket Commits API and the Atlassian Bitbucket Pipelines API. The agentic access profile maps 2,550 operations, 1,290 of them acting. Agent skills, dry-run mode, delegated identity, reversibility and error semantics are all lit on the Agent Readiness score. The Kin Score is 73.6, in the exemplar band, and the Agent Readiness score is 42.2, agent-ready.
But the MCP server dimension is unlit. So are protected resource metadata and dynamic client registration. That is the record of a company running a remote MCP server that now supports OAuth sign-in. If you had trusted the catalog alone to tell you whether Atlassian offers this, it would have told you no.
The post doesn't hedge about whose mistake this is. It's the third time the series has found a major provider's MCP server missing from its record, after Kong and AWS, and the gap is on the catalog's side. A server that moved to a v2 endpoint is exactly the case a probe built against an older address would miss.
So here is what you take away. Atlassian has put Jira, Confluence and Bitbucket behind one sign-in for any AI client, and your existing permissions still apply. If you used the earlier connector, expect to remove and re-add it for the v2 endpoint. And when a directory says a provider has no MCP server, check the provider's own announcement too, because by its own account the catalog needs to find the door Atlassian moved.
Read the original: https://apis.io/2026/10/22/atlassian-opens-bitbucket-to-ai-clients-over-oauth-and-the-record-has-not-found-the-server/