What's supported today

When you are deciding whether a platform fits your stack, one question comes before the others: what does it actually connect to today, not on a roadmap. The question is simple; the answer, on most platforms, is not. This page is the plain answer for Disco Parrot, organized by the categories that actually behave differently, so you can match what you run against what the product reaches.

The categories matter because they are not interchangeable. A two-way work-item integration, a repository the agent works in, a file store you import from, and a place notifications go out all have different credential models and different trust boundaries. The full reasoning behind the categories lives in integrations and providers; this page is the at-a-glance roster.

What connects today

Each of these has its own how-to, and the one-line version of each is worth having in front of you. Azure DevOps keeps initiatives, plans, and test cases in step with work items, mapped to your own work-item types. GitHub makes chat code-aware, so the agent reads your real pull requests, checks, and code rather than talking about code in general. Repository providers are the code an agent clones into a sandbox and opens a pull request back to. Document providers bring files in read-only, one person's account at a time. Notification channels carry alerts out and never read back; the AI runtimes are the models an agent reasons on; sign-in is how a person logs in, and nothing else.

Reached as a tool, not an integration

There is a second, much longer list of systems the agent can reach, and keeping it separate from the one above is the single most useful distinction on this page. Jira, Linear, Slack, Notion, Sentry, Confluence, Figma, and many more are available to the agent as MCP tools: the agent can search a Jira project, post to a Slack channel, or read a Linear issue when a conversation calls for it.

What makes them tools rather than integrations is what they do not do. There is no two-way sync between a Linear ticket and a Disco Parrot plan, no field mapping, no records mirrored across. There is a server the agent can ask to read or write one thing at a time, governed by the per-tool controls under approved actions. Each earns its place, but they are different categories, and a buyer who conflates them ends up expecting a sync that was never the point.

Sign-in is not a code host

People sign in to Disco Parrot with Microsoft Entra or Google, verified over OAuth. That is the whole sign-in list, and it is worth stating plainly because of what is not on it: GitHub, Azure DevOps, and your document providers are credentials you bring to reach a downstream system, not ways you log in. Your workspace identity is one thing; the access you connect to GitHub or Drive is another. That separation is deliberate, and integrations and providers covers why it matters when an engagement ends or a credential is revoked. For how people sign in, link more than one login, and manage their sessions, see authentication and identity.

Some capabilities ride on your plan

A handful of the rows above turn on with the commercial plan rather than being on for every workspace.

Which tier carries which capability is a commercial question rather than a technical one, so your plan is where that answer lives, not this page, and the Capabilities panel on the Plan and Usage page shows the ones your workspace has turned on right now.

A few names you will not find here

Naming what a product is includes naming what a word does not mean here, so the categories stay honest:

• Connectors is not a Disco Parrot term. What other tools lump under one word, this product splits into the categories above, because their credential and trust models genuinely differ.
• GitLab and Bitbucket are not repository providers today. The provider model is built to take more kinds; GitHub and GitHub Enterprise are the two wired now.
• Jira and Linear are not work-item integrations. They are MCP tools, the tool category above.
• Slack is not a notification channel. Notifications go to the in-app inbox, email, and Teams; Slack is an MCP tool the agent calls, not a place notifications are delivered.
• GitHub is not a sign-in provider. Sign-in is Microsoft Entra and Google.

Naming these is not a list of gaps; it is the same precision the categories are built on. A short, honest roster you can act on beats a long one you have to second-guess.

Why we name it this way

Most platforms answer "what do you integrate with" by reaching for the longest list they can defend, because a long list looks like capability. The cost is that the list stops meaning anything: a two-way sync, a tool call, and a single sign-on all get filed under one friendly word, and a buyer cannot tell which is which until they are mid-deployment. Disco Parrot answers the question the other way, with a short roster organized by how each connection actually behaves, because the category is the part you need to plan around. When someone asks what the product connects to, the honest, useful answer is the one you can read in a minute and act on without a follow-up call.

For a planner, this page is the quick check before you promise a workflow: the systems your team lives in, and which of them Disco Parrot keeps in step versus reaches as a tool.

For an engineer, it is the map of where your code, your files, and your work tracker plug in, and which of them is a managed connection versus a tool the agent calls, with a link to each how-to so you wire the ones you need and skip the ones you do not.

For a lead, the roster is short on purpose, so the answer to "what can this touch in our stack" is a page you read once rather than a matrix you maintain.

For the person who has to approve what connects to your systems, the value is the category lines: an integration, a tool, a provider, and a sign-in carry different credentials and different blast radius, and naming them apart is what lets you reason about each on its own terms rather than as one undifferentiated bucket.