Every AI orchestration platform publishes a logo wall, and every logo wall is answering the wrong question. The number of integrations tells you what the vendor has built. It tells you nothing about what happens when the tool you actually depend on is not on the wall.
That is the question worth asking, because the answer is usually the same: you file a request, you wait, and the vendor prioritises it against every other request. Your workflow is blocked on someone else's roadmap.
What AI orchestration platforms connect to, and what they do not
Compare any three platforms in this category and you will find the same shape. A large catalogue of official connectors, built and maintained by the vendor, plus a generic webhook for everything else. The catalogue is the product. The webhook is the apology.
This model has a ceiling that never moves. However many connectors exist, the set is finite and controlled by someone other than you. And the connectors that get built are the popular ones, which means the tools specific to your niche are structurally last in line.
Crew Studio is built the other way round. Eight native connections handle what most operators reach for daily. Everything past that is MCP, which means the ceiling is not the catalogue. The ceiling is whether the tool has an API at all.
So the useful comparison between AI orchestration platforms is not the length of the catalogue. It is what sits behind the catalogue on the day your tool is not in it. A request form and a queue, or an open standard you can build against without asking anyone.
The native integrations
Eight connections ship ready, chosen because they are where operators actually work rather than because they made the wall look full. Each is bidirectional: the Crew reads from them and writes into them.
- Gmail
- Specialists read a thread for context and draft replies in the Studio's voice. On Confirm autonomy nothing sends without you. A support triage specialist can sort an inbox before you open it, which is a different job from writing the replies.
- Notion
- The crew writes into your content base, not just reads from it. A content plan lands as pages with the properties filled, not as a block of text you have to restructure. Prior briefs held in Notion become Studio context.
- Slack
- Reads channels for context and posts synthesis where the conversation is happening. Useful mostly for operators working with a client team rather than alone.
- GitHub and Linear
- Issues, pull requests, and the ability to read what actually shipped rather than what was planned. A changelog written from the repository is accurate in a way one written from memory is not.
- Stripe
- Revenue, churn and cohort data as input to a brief. A growth specialist reading real numbers produces a different recommendation from one reading your description of the numbers.
- HubSpot and Calendly
- Deal context and meeting scheduling. A pre-meeting brief assembled from the CRM plus the Studio's history of the account, rather than from whatever you remember on the way to the call.
WATCH IT RUN
Connect your stack
Below is what the crew does inside each connection, rather than the logos on their own. The last card is the one that matters most, and it is not a logo.
One detail that matters more than it looks: integrations are attached to the Studio, not to the account. Your client Studio reaches their Notion. Your personal Studio reaches yours. Neither can see the other's, which is the difference between a tool you can use for client work and one you cannot.
Gmail
Reads the thread, drafts the reply in your voice, holds it for approval.
Notion
Writes into your content base with properties filled. Not just reading it.
Stripe
Reads cohort retention so a growth brief argues from numbers, not from your summary of them.
GitHub · Linear
Writes the changelog from what shipped, not from what was planned.
Anything else · MCP
Your own server, your own credentials, your own tools. Including the ones we have never heard of. No request form, no waiting list, no roadmap vote.
integrations attached per Studio · your client's Notion is not your Notion
What MCP changes
MCP is an open standard for connecting AI systems to external tools. Stripped of the acronym, it means a tool can describe what it can do in a format any AI system understands, without the AI vendor having built anything specific for it.
The connection stops belonging to the vendor.
A native integration is a piece of the vendor's product. An MCP server is a piece of yours. If you leave, it leaves with you.
The ceiling moves from the catalogue to the API.
The question stops being whether Crew Studio supports your tool and becomes whether your tool exposes itself at all. That is a much better question to be limited by.
Niche tools stop being last in line.
A vendor prioritises connectors by user count, which structurally deprioritises anything specific. MCP has no queue.
Internal tools become reachable.
The spreadsheet, the internal dashboard, the thing your developer built two years ago. None of these will ever appear on anyone's logo wall, and all of them can be reached.
None of that makes the native connections less useful. It does mean the ceiling on most AI orchestration platforms is a commercial decision rather than a technical one, which is worth knowing before you plan a month of work around a connector that does not exist yet.
Building a connection Crew Studio has never listed
This is the part where most platforms would say «contact sales». The honest version is that it depends on whether an MCP server already exists for your tool.
If one exists, it is configuration.
A growing number of tools publish their own MCP server, and connecting is a matter of pointing Crew Studio at it and authorising. No code.
If one does not, it is development work.
Someone has to write it. It is not large work for a developer, but it is work, and pretending otherwise would be dishonest. If you do not have a developer, this option is theoretical for you today.
What you get either way is ownership.
The server is yours. It works with Crew Studio and with anything else that speaks MCP, which is an increasing share of the category.
Integrations are attached per Studio
This is the design decision that separates a tool you can use for client work from one you cannot, and it is easy to miss because it sounds like a detail.
Each Studio authorises its own accounts.
Your client Studio reaches their Notion, their Slack, their Stripe. Your personal Studio reaches yours. A specialist working in one has no path to the other's, which is a structural property rather than a permission you set.
Offboarding is one action.
When a client relationship ends, deleting the Studio removes the connections with it. There is no audit of which account still has a token where.
The same tool can be connected twice, differently.
Two clients both on HubSpot means two authorisations in two Studios. Neither can see the other's pipeline, even though the integration is the same one.
It makes the isolation credible.
Sealed memory is worth little if every Studio shares one Gmail token. Isolation that stops at the context boundary and not at the integration boundary is not isolation, and this is where most tools stop.
Who this matters to
Operators in a niche.
If your stack includes tools nobody has heard of, the catalogue model was never going to serve you and the number on the logo wall was always irrelevant.
Agencies handling client stacks.
Every client arrives with a slightly different set of tools. Per Studio integrations plus MCP is the only shape that survives that.
Anyone who has been burned by a deprecation.
A native connector that a vendor decides to retire takes your workflow with it. A server you own does not get retired by someone else.
Operators who expect their stack to change.
The tools you use in two years are not the tools you use today. A ceiling set by whether something has an API ages better than one set by a catalogue someone else maintains.
The common thread is that all four are limited by someone else's roadmap. AI orchestration platforms that own every connection decide, on your behalf, which tools are worth supporting and in what order. The only way out of that is a connection you can build and keep.
WHERE IT DOES NOT HELP
When integrations are not your blocker
If you work mostly in documents, you may need fewer connections than you think.
Exporting a synthesis and pasting it once is not the bottleneck. The bottleneck is producing the synthesis.
If your tool has no API, no platform can help.
MCP connects to what exposes itself. A closed desktop app with no interface stays out of reach, and no vendor will change that.
If you want a specific connection rather than a team, look at a workflow tool.
Connecting two apps on a trigger is what Zapier and n8n do, more cheaply and more directly. Crew Studio connects apps so a Crew can work inside them, which is a different job.
If compliance governs your stack, check before you connect.
Crew Studio does not offer SSO or SAML at this stage. An organisation with a procurement process requiring them should wait.
If you have no developer and your tool has no MCP server, be honest about it.
The open ceiling is real but it is not free. Check whether the tools you depend on publish a server before deciding the ceiling matters to you.
SIDE BY SIDE
Crew Studio compared to a closed integration marketplace
Two rows go clearly to the marketplace, and if your stack is entirely mainstream tools, breadth today beats a higher ceiling later. The trade only pays off when something you depend on is not on the list.
There is a version of this comparison that resolves itself over time. Native connections keep shipping, so the breadth gap narrows every quarter, while the ceiling difference is structural and does not. Whether that matters to you depends entirely on whether you can wait.
| Capability | Crew Studio | A closed integration marketplace |
|---|---|---|
| Native connections | 8 at launch, more shipping | Often hundreds |
| Connecting an unlisted tool | Yes, via your own MCP server | No. You wait for the vendor. |
| Who owns the connection | The operator | The vendor |
| Isolation per project | Per Studio | Usually per account |
| Setup for a native connection | OAuth, a few clicks | OAuth, a few clicks |
| Setup for an unlisted tool | Needs a developer if no server exists | Not possible at all |
| Breadth today | Narrower | Broader |
| Ceiling | Whether the tool has an API | The marketplace catalogue |
| Agents acting inside the tool | Yes, on the Studio's autonomy level | Varies |
What is not connected yet
The roadmap matters more than the current list when you are deciding whether to commit, so here is the honest version rather than a teaser.
Reach ships on Telegram only.
WhatsApp, Email and iMessage are planned and not available. If Telegram is not somewhere you already are, adding it just for this is a poor trade.
No SSO, no SAML.
This blocks procurement at most companies above a certain size, and it is documented on the security page rather than omitted.
Google Drive, Airtable and Shopify are frequently asked for and not yet native.
All three publish or are close to publishing MCP servers, which is the intended path rather than a workaround.
No native connection acts without an autonomy level allowing it.
Worth repeating here because it is the question operators ask before authorising anything: connecting an app does not grant the crew permission to use it destructively.
KEEP READING
Related
QUESTIONS
Questions about integrations
Which apps does Crew Studio connect to?
Crew Studio ships native connections to Gmail, Notion, Slack, GitHub, Linear, Stripe, HubSpot and Calendly, with more in the roadmap. Any other tool connects through a custom MCP server, including tools Crew Studio has never listed.
What is an MCP server and why does it matter?
MCP is an open standard for connecting AI systems to external tools. Crew Studio is MCP first, which means an operator can connect any service that exposes an MCP server without waiting for an official integration. The connection belongs to the operator, not to the vendor.
Can Crew Studio publish or send things on my behalf?
Only at the autonomy level the operator sets. On Ask and Confirm, nothing leaves the Studio without approval. On Ship on trigger, defined actions execute inside the connected apps. The level is configured per Studio and can be changed at any time.
What happens when an app changes its API?
Native integrations break the way every integration breaks, and we fix them. The reason this page insists on MCP is that it changes who is waiting: a connection you built through your own MCP server is yours to repair the day it breaks, on your timetable rather than ours. That is the trade, stated plainly, and it is why the ceiling of a fixed integrations list matters more than its length.