# Vendor MCP servers vs single control plane

> Vendor MCP servers vs single control plane is a trade: each vendor's server gives depth, one plane gives one address, one rule surface and one audit log.

**TL;DR** Adopting vendor MCP servers vs a single control plane is a trade between depth and consistency. A first-party server usually exposes the deepest tool surface for its own app, because the vendor built it against its own API. Elaichi puts one address in front of many apps, with one set of role restrictions and one audit log. It can also carry a vendor's own MCP server as a native MCP connector, where depth matters more than uniformity.

## The situation

In October 2026 the list of SaaS vendors running their own MCP server is long. An IT team can no longer treat it as a novelty. Notion, HubSpot, Slack, Ramp, ClickUp, Gusto, BambooHR, Atlassian, Basecamp, PagerDuty and Missive all publish one. Each runs under that app's own permission model, reading and writing only what the authorizing user can already reach there (checked October 2026, per [Notion's MCP overview](https://developers.notion.com/guides/mcp/overview)). So the question in front of you is no longer whether to use MCP. It is vendor MCP servers vs single control plane: each app's assistant access wired up on its own terms, or [one plane that serves them all](/blog/what-is-an-mcp-control-plane/).

MCP is the Model Context Protocol, the standard an AI client uses to discover and call tools. That choice decides how many addresses your employees configure. It also decides where a restriction lives, and how many logs an auditor reads.

## What does a first-party vendor server do better?

It exposes the deepest tool surface for its own app. The vendor wrote it against its own API, and ships new tools as that API grows. Nobody knows Ramp's object model like Ramp.

The evidence sits on the vendors' own pages. Ramp MCP both reads Ramp data and writes to it ([Ramp, checked October 2026](https://support.ramp.com/ramp-mcp)). It covers spend analysis, approving or rejecting transactions and reimbursements, editing transactions, and card actions such as locking a card. Atlassian's one server spans Jira, Confluence, Jira Service Management, Bitbucket, Compass and Loom. Its write_confluence permission group includes tools that change who can see content ([Atlassian, checked October 2026](https://support.atlassian.com/atlassian-ai-gateway/docs/supported-tools/)). Gusto says running payroll through its MCP server always stops for a human decision ([Gusto, checked October 2026](https://gusto.com/product/agents)). The assistant assembles the run, and the admin must confirm.

There is also no second vendor in the path. The app's own server adds no new company to your subprocessor list and no new sign-in to explain. It adds no new place for a connector to lag behind an API change. If one app carries the whole use case, this is the honest answer, and Elaichi is not the shorter path.

## Where adopting each server directly starts to hurt

The cost is not in any one server. It is in the Nth one, and it is paid in addresses, in rule-setting surfaces, and in logs.

Each vendor publishes its own endpoint: Slack at https://mcp.slack.com/mcp, HubSpot at https://mcp.hubspot.com, ClickUp at https://mcp.clickup.com/mcp. PagerDuty serves https://mcp.pagerduty.com/mcp, with a separate EU host at https://mcp.eu.pagerduty.com/mcp (each checked October 2026 on the vendor's own docs). Each has its own admin screen and its own vocabulary for what a role may do. Each connection is approved separately by each employee in each client.

The controls differ in kind, not just in wording. Missive's MCP server is off by default until an owner or admin enables it. Missive's own admin page says an admin cannot restrict which AI apps members connect, or limit which permissions members grant ([Missive, checked October 2026](https://missiveapp.com/docs/ai/mcp/server/admin)). Nor can an admin enable MCP for some members and not others, or see another member's connected apps. Without its Everything AI add-on, ClickUp caps MCP calls per day by plan. It allows 100 per 24 hours on Free Forever and 5,000 on Enterprise ([ClickUp, checked October 2026](https://clickup.com/blog/how-to-use-clickup-mcp-server/)). BambooHR's server omits fields a caller cannot read with no marker showing anything was withheld ([BambooHR, checked October 2026](https://documentation.bamboohr.com/docs/mcp-server)).

None of that is a flaw. It is each vendor building for its own product, which is the right thing for them to do. But none of the app vendor pages read for this post describes one address or one restriction set across apps from more than one vendor. None describes one audit trail or one offboarding action either. Each describes only its own product. That gap is the whole argument on the other side.

## What one control plane gives you instead

One address, one place where restrictions live, and one audit log across every connected app. Elaichi serves MCP at a single endpoint, https://api.elaichi.ai/mcp, the same string for every organization. Claude, ChatGPT and Cursor all sign into it with OAuth. Which organization, person and tools a client reaches comes from the OAuth grant behind the token, not from the URL.

The consequences are concrete:

- **One rule surface.** A restriction rule targets a role or one member, and can name whole connectors or single tools. One rule can name connectors from any number of vendors. So "read-only in the finance apps" is written once, rather than in each vendor's admin screen.
- **One audit log.** An organization has one audit log across all its connectors. Calls to different vendors' apps are written to the same per-organization log, and read back through the same place. Every connected-tool call that reaches execution records the person, the connector, the connection and the tool. It also records [what it touched](/blog/what-an-ai-audit-log-must-capture/) and which MCP client made the call.
- **One offboarding action.** Removing a member revokes every live MCP OAuth grant they hold in that organization. Grants are re-read on every request, so their MCP clients fail on the next call. It does not remove their accounts in the connected apps; that still happens in each app or through the identity provider.
- **No per-client address.** There is no per-user, per-team or per-toolbox MCP URL to hand out or rotate. Each person still connects their client once and approves their own grant.

The trade is real. For a catalog connector, Elaichi is itself the MCP server the client calls, and Elaichi authors and runs it. That connector tracks the vendor's API as Elaichi maintains it, not as the vendor ships it. On depth for one app, a first-party server generally wins.

## Vendor MCP servers vs single control plane, side by side

The difference is not tool quality. It is how many places a decision lives, and how many places you look afterwards.

| Axis | Each vendor's own MCP server | One control plane (Elaichi) |
| --- | --- | --- |
| Addresses to configure | One per vendor, each with its own admin screen | One, https://api.elaichi.ai/mcp, the same for every organization |
| Where a restriction lives | In each vendor's admin surface, in that vendor's vocabulary | One rule on a role or a member, naming connectors from any number of vendors |
| Audit trail | Whatever that vendor's own page documents | One log across every connected app, with the person, connector, connection, tool and MCP client |
| Offboarding | Per app, as far as each vendor's own page documents | Removing or suspending the member revokes their grants, and clients fail on the next call |
| Tool depth for one app | Deepest: written by the vendor against its own API | A catalog connector tracks the API as Elaichi maintains it |
| Extra vendor in the path | None | Elaichi |

## Can you have both?

Yes, for the apps where depth matters. Elaichi's catalog holds two kinds of connector. Most are connectors Elaichi authors and runs itself. The rest are native MCP connectors, where the vendor builds and runs its own MCP server. Elaichi handles sign-in, access and audit in front of it.

The catalog snapshot synced on 7 October 2026 marks many of its connectors native MCP, each with a vendor support contact. Datadog, Linear, GitLab, PostHog and Miro are among them. For a native MCP connector, the vendor's tools come through the same address, and the same search_tools and execute_tool, as every other connector. Each person signs in to Elaichi as themselves and connects with their own sign-in at the vendor. Restrictions and OAuth scopes are checked before a call leaves Elaichi, and every call that runs is written to the audit log. Reports about the tools go to the vendor's support contact, because the vendor built them.

A team can also bring a server in itself. An organization on Gold can add a remote MCP server as its own connector, created by an Org Owner or Org Admin. The server speaks MCP over Streamable HTTP. Members then connect it with their own sign-in. Its tools are discovered per connection, because different members' accounts can see different tools. To a restriction rule, a remote tool looks like any other tool. Limits apply: 25 organization-owned remote MCP connectors per organization, 500 tools per connection, and a 60-second deadline per call including retries.

So the fork is not permanent. The deep server you want for one app can sit behind the one address you want for the rest. The reading on which specific vendor servers the Elaichi team has tested is a question to put to us, not a claim in this post.

## How to decide, in order

1. **Count the apps that actually need assistant access.** If it is one, adopt that vendor's server directly and stop. The case for a plane starts at the second or third app, not the first.
2. **Check whether that app's server has the admin controls you need.** Read the vendor's own admin page. Missive's says enable-or-disable is the control; Atlassian's documents permission groups and domain allowlists. The answer differs per vendor.
3. **Write down who has to answer for the calls.** An auditor may ask "who ran what, in which app, last quarter". If so, one audit trail across apps is worth more than the last stretch of one app's tool surface. If nobody asks, it is not.
4. **Decide per app, not per company.** Depth where depth pays, one plane for the long tail, native MCP connectors or a remote MCP connector where you want both.

If that count is low, read [when you don't need an MCP gateway yet](/blog/when-you-dont-need-an-mcp-gateway/) before buying anything. If you are weighing registries against authored connectors, [MCP server registry vs first-party connectors](/blog/mcp-registry-vs-first-party-connectors/) takes that fork apart. For how each native MCP connector is governed in practice, see [running vendor servers through Elaichi](/blog/vendor-mcp-servers-through-elaichi/). You can also browse what is already authored in the [connector catalog](/connectors/).

## FAQ

### Do SaaS vendors' own MCP servers enforce the user's existing permissions?

The vendors' own pages say they do, each within that app's permission model. Notion, HubSpot, Slack, Ramp, ClickUp, Gusto, BambooHR, Atlassian, Basecamp, PagerDuty and Missive each publish an MCP server (checked October 2026). Each reads and writes only what the authorizing user can already access in that app. What those pages do not describe is one set of rules, one audit trail or one offboarding action spanning apps from more than one vendor. Each page covers only its own product.

### Does a single MCP control plane replace a vendor's own MCP server?

Not necessarily. Elaichi's catalog holds connectors Elaichi authors and runs itself. It also holds native MCP connectors, where the vendor builds and runs its own MCP server. Elaichi handles sign-in, access and audit in front of it. A team on the Gold plan can also add its own remote MCP server as a connector, created by an Org Owner or Org Admin. An organization can hold up to 25 of its own remote MCP connectors. So a vendor's deep server can sit behind one governed address rather than beside it.

### How many MCP addresses do employees configure with a control plane?

One. Elaichi serves MCP at https://api.elaichi.ai/mcp, the same string for every organization, and Claude, ChatGPT and Cursor all sign into it with OAuth. There is no per-user, per-team, per-toolbox or per-client address. Each person still connects their client once and approves their own grant. That grant, not the URL, decides which organization, person and tools the client reaches.

### What happens to an employee's AI access across apps when they leave?

In Elaichi, removing or suspending a member revokes every live MCP OAuth grant they hold in that organization. Grants are re-read on every request, so their MCP clients fail on the next call. Reactivating the member does not restore the grants; they have to consent again. That ends their reach through Elaichi. It does not remove or deactivate their accounts in the connected apps. Those stay in place until they are deprovisioned in each app or through the identity provider.

### Is a first-party vendor MCP server deeper than a third-party connector?

For that one app, usually yes. The vendor wrote the server against its own API, and ships new tools as the API grows. The vendor's pages show the breadth. Ramp's server covers spend analysis, approving transactions and reimbursements, editing transactions and card actions, and Atlassian's one server spans Jira, Confluence, Jira Service Management, Bitbucket, Compass and Loom (both checked October 2026). The trade is coverage depth for one app against one address, one rule surface and one audit trail across many.

## Read next

- [Open source MCP servers vs paid: the real cost](/blog/free-mcp-servers-vs-paid-control-plane/) — The real choice in open source MCP servers vs paid is operating cost: sign-in, credentials, per-person access, the audit trail and offboarding, itemized.
- [Hosted MCP gateway vs running the gateway yourself](/blog/hosted-mcp-gateway/) — A hosted MCP gateway runs the checkpoint every AI tool call passes through. Self-hosting puts it on your servers. Six questions decide which fits.
- [MCP audit log comparison: what each shape records](/blog/audit-log-comparison-mcp-tools/) — An MCP audit log comparison across four shapes: what each one records about intent, the account reached, arguments, and whether AI actorship is a field.