Cursor Team MCP Marketplace: Setup & Governance (2026)

TL;DR

Cursor v3.10 (June 30, 2026) lets admins configure a Team MCP server once and distribute it across cloud agents, the agents window, IDE, and CLI — and scope who can see it by organization group.

• The change: per Cursor’s own changelog, “Admins can now configure Team MCP servers once and distribute them across cloud agents, the agents window, IDE, and CLI.”
• Access control: Team Marketplaces now support Organization Groups alongside the existing SCIM directory groups, set under Dashboard → Plugins → Team Marketplaces.
• Developer side: approved servers install from the Customize tab with one click, no hand-edited mcp.json.
• Plan gate: Teams (one marketplace) or Enterprise (unlimited) — not on Free or individual Pro.
• What it isn’t: an MCP protocol extension or an authorization system. It’s Cursor-side config distribution — see how that differs from EMA below.

Why this exists

Before this update, standardizing an MCP server across a team meant standardizing a copy-paste. Every developer opened their own ~/.cursor/mcp.json (or the Cursor Settings MCP panel) and hand-entered the same command, args, and environment variables — including any secrets — for every server the team wanted.

That has three predictable failure modes: a new hire re-types every server from a Slack message instead of inheriting anything; a config change means messaging the team a new JSON snippet and hoping everyone pastes it correctly; and IT has no single place to see which servers are actually configured across the org, let alone enforce which ones should be.

Cursor has been building toward closing that gap in stages, not in one release:

Team MCP servers built for cloud agents lived in their own silo — Dashboard → Integrations & MCP — separate from the general plugin marketplace. 3.10 is the release that actually wires the two together, which is why the changelog names both pieces in its title: MCPs, and Organizations, in Team Marketplaces.

The pieces, and how they connect

Five named pieces, and the order they interact in:

• Team MCP server — the server definition (a command to launch, or a hosted URL) an admin sets up once, under Dashboard → Integrations & MCP.
• Team Marketplace — the private, per-organization catalog (Dashboard → Plugins) where approved servers and plugins get listed for the team to browse.
• Marketplace Access — the visibility gate on a marketplace: which Organization Group or SCIM directory group can see it at all.
• Installation mode — a per-plugin setting: Default Off, Default On, or Required.
• Customize — the tab, shipped in 3.9, where a developer actually sees and installs what’s been shared with them.

┌───────────────────────────────────────────────────────────────┐
│   Cursor Team MCP Marketplace — one config, four surfaces        │
├───────────────────────────────────────────────────────────────┤
│ Admin                                                             │
│  Dashboard -> Integrations & MCP                                  │
│    configure Team MCP server (once)                               │
│             |                                                     │
│             v   "Add to Team Marketplace"                         │
│  Dashboard -> Plugins   (Default marketplace, auto-created)       │
│    set Installation Mode:  Off / On / Required                    │
│    set Marketplace Access: Organization Group / SCIM group        │
│             |                                                     │
│             v   (only members of the scoped group see it)         │
│ Developer                                                          │
│  Customize tab -> install with one click                          │
│             |                                                     │
│             v   same config now live in:                          │
│  Cloud Agents · Agents Window · IDE · CLI                         │
└───────────────────────────────────────────────────────────────┘

Nothing in that chain is a new MCP primitive. A Team MCP server is an ordinary MCP server; “team” describes how Cursor’s dashboard distributes the config, not anything the protocol or the server itself knows about.

Admin setup, step by step

Every step below is stated directly in Cursor’s MCP docs and plugins docs. None of it requires a developer to touch a config file.

1. Configure the server. Under Dashboard → Integrations & MCP, add your Team MCP server the way you’d define any MCP server — a command to launch, or a hosted URL. This already makes it available to cloud agents; that part of the flow predates 3.10.
2. Link it to a marketplace. Still under Integrations & MCP, find the server listed under Team MCP Servers and select Add to Team Marketplace. If the org has no marketplace yet, Cursor creates a “Default” one and links the server to it automatically.
3. Set who can see it. Open Dashboard → Plugins, open that marketplace, and under Marketplace Settings → Marketplace Access choose specific Organization Groups or leave it on the SCIM directory groups it already used.
4. Choose the installation mode. Default Off, Default On, or Required — set per plugin, covered in full below.
5. Optional: build a marketplace from scratch. Dashboard → Plugins → Add Marketplace, either empty or via Import from Repo against a GitHub repository of plugins.
6. Keep it current. Enable Auto Refresh (requires the Cursor GitHub App) so edits pushed to the tracked branch flow through automatically — Cursor re-indexes at most every 10 minutes — or click Refresh by hand.

Org Groups vs SCIM

Two group types can scope a marketplace, and they overlap on purpose rather than by accident. SCIM directory groups are the original, team-level mechanism: membership syncs automatically from your identity provider, scoped to one team. Organization Groups, new in 3.10, are broader — Enterprise admins define them across the whole Cursor organization, not one team, and each group can either sync from SCIM or be managed manually inside Cursor.

Cursor’s docs are explicit that nothing breaks if you ignore this: existing marketplaces keep using their directory groups, and only new assignments need Organization Groups. Team admins always retain access regardless of grouping — and worth repeating because it surprises people, a marketplace with no groups selected is visible to the whole team, not to nobody.

What developers actually see

Everything above is admin-side. From a developer’s seat, the entire feature is one screen: Customize. Approved servers set to Default Off show up there to install with a click; Default On servers are already installed, removable if unwanted; Required servers are there and stay there. No command, no args array, no env block, no restarting the client and hoping the JSON parsed.

One thing the docs don’t spell out: how a Team MCP server’s own secrets — an API key a specific server needs — are handled per developer once it’s installed. Whether each teammate supplies their own credential or inherits the admin’s isn’t documented either way in the pages this guide draws from. Confirm that behavior before you push out any server that’s meant to act as the individual developer rather than a shared service account — more on this in common mistakes.

Team Marketplaces vs. Enterprise-Managed Authorization

Both ship in 2026, both target admins, and it’s easy to conflate them. They govern different layers. MCP Enterprise-Managed Authorization (EMA) is a formal MCP protocol extension: an identity provider decides, at request time, whether a client’s token exchange for a given server succeeds. Team Marketplaces are a Cursor product feature: an admin decides which config a developer sees and can install.

They stack rather than compete. Team Marketplaces solve “does this developer have the right config on their machine”; EMA solves “can this identity actually get a token from this server, right now.” A Cursor shop rolling out a remote MCP server org-wide plausibly wants both: the marketplace so nobody hand-types a URL wrong, and an identity-backed authorization step so the access decision isn’t just “the JSON showed up on your laptop.”

What we got wrong

Three assumptions this guide started with, corrected against the actual docs:

• We assumed a Team Marketplace was the public marketplace with a team filter. It isn’t. cursor.com/marketplace is a public, open catalog anyone can browse. A Team Marketplace (Dashboard → Plugins) is private to the organization; nobody outside it ever sees it exists.
• We assumed linking a server to the marketplace was the whole job. It isn’t — the docs say plainly that “linking an MCP server to a marketplace does not install or enable it for everyone.” Skip the installation-mode step and you’ve published a server nobody has installed anywhere.
• We assumed “Team MCP” was a new MCP-spec concept, on the same footing as EMA. It isn’t. A Team MCP server carries nothing special at the protocol level — it’s Cursor’s own distribution plumbing wrapped around an entirely ordinary MCP server.

Common mistakes

• Leaving Marketplace Access empty on a “soft launch.” An empty group list doesn’t mean nobody sees it — it means the whole team does. If you want a limited pilot, set the group before you publish, not after.
• Expecting a GitHub-backed marketplace to update live without Auto Refresh. Without it (and the Cursor GitHub App installed), changes sit until someone clicks Refresh. Even with Auto Refresh on, re-indexing happens at most every 10 minutes — plan around that, don’t assume instant propagation.
• Assuming a switch to Organization Groups migrates old marketplaces automatically. It doesn’t. Marketplaces already scoped to SCIM directory groups keep that configuration until an admin deliberately adds Organization Groups.
• Rolling out a per-user-secret server team-wide before checking how credentials propagate. If a server needs to act as each individual developer — not a shared bot account — test with one server and one non-critical account first. The docs this guide checked don’t document per-user secret handling either way.
• Treating installation as governance. Getting a server onto every laptop is not the same as controlling what an agent does with it once connected. See the audit gap in the next section.

Limits & who it’s for

The audit gap is worth naming directly. Nothing in Cursor’s plugin or MCP docs describes logging which developer ran which tool call through a Team MCP server, or what changed as a result. The feature controls distribution: who can see and install a config. It has no visibility into what an agent does after that — so if you need a real audit trail of tool calls, plan to add it at the MCP-server or gateway layer yourself.

Plan gate, for completeness: Teams accounts get one team marketplace, Enterprise accounts get unlimited marketplaces, and neither Free nor individual Pro plans have the feature.

Community signal

Reaction to the specific 3.10 line item has been modest — it shipped as one entry in a fast-moving changelog, not a standalone launch. The clearest developer response came as a quote-tweet the day after release:

That take reads the feature as an infrastructure bet, not a convenience tweak — a step toward teams defaulting to fleets of cloud agents rather than one developer, one IDE session. The more skeptical read came from an independent hands-on review of Cursor’s broader plugin marketplace, which landed on a measured verdict:

Both critical voices point at the same underlying fact: the marketplace makes existing capability easier to discover and roll out, it doesn’t add a new governance primitive underneath it.

The verdict

The bigger picture

2026’s enterprise MCP tooling is splitting into two layers, built by different parts of the ecosystem. Protocol-level authorization — EMA — is client-agnostic by design: any MCP client can implement it, and it plugs into whichever identity provider the org already trusts. Product-level distribution — Team Marketplaces — is the opposite bet: fast to ship, immediately useful, and entirely Cursor-shaped. Nothing about a Team Marketplace config travels if half the team switches to a different client next quarter.

That trade is worth stating plainly rather than glossing over. Centralizing MCP configuration buys consistency and predictability for admins. It spends some of the flexibility that made MCP appealing in the first place — the idea that any developer could wire up any server in minutes without waiting on a platform team. Cursor shipped this in three visible steps over four months (2.6 → 3.9 → 3.10), which cuts both ways: the feature is improving fast, and it’s also still a moving target for anyone documenting or depending on it.

For further reading on the protocol side of this split, see our MCP primer and our breakdown of Enterprise-Managed Authorization. For how Cursor stacks up against other AI coding IDEs more broadly, see Cursor vs Windsurf vs Antigravity vs Kiro.

Frequently Asked Questions

Glossary

Sources

Primary

• MCPs and Organizations in Team Marketplaces — Cursor changelog, v3.10, June 30, 2026.
• Model Context Protocol (MCP) — Cursor docs.
• Plugins & Team Marketplaces — Cursor docs.
• Organization Groups — Cursor docs.
• MCP Apps and Team Marketplaces for Plugins — Cursor changelog, v2.6, March 3, 2026.
• @cursorreleases, July 1, 2026 — first-party summary of the 3.10 change.

Community & critical voices

• @mattlam_, July 1, 2026 — developer reaction on the cloud-agent trajectory.
• “I Tried Cursor’s New Plugin Marketplace” — Engincan Veske, hands-on review.
• Cursor 2.6: MCP Apps and Team Marketplaces for Plugins — Cursor community forum announcement thread.

Internal links

• /blog/mcp-enterprise-managed-authorization-2026 — the authorization layer this feature doesn’t replace
• /blog/what-is-mcp — protocol primer
• /blog/cursor-vs-windsurf-vs-antigravity-vs-kiro-2026
• /clients/cursor
• /servers — browse all 3,000+