Cursor Team MCP Marketplace: Central MCP Server Distribution Changes Your Agent Tool Routing Policy

The question isn't whether your team uses MCP servers in Cursor. At this point, most engineering teams do. The question is who decides which MCP servers each agent can reach — and whether that decision is made once, consistently, or scattered across hundreds of individual developer configs.

Cursor's latest Team Marketplace update settles that question with two additions: Team MCPs in team marketplaces and org-group access control. Together they move MCP governance from per-seat configuration to centralized operator control.

What happened

Cursor has expanded its team marketplace feature to cover MCP servers. Admins can now configure Team MCP servers once and automatically distribute them across four surfaces: cloud agents, the Agents window, the IDE, and the CLI.

When an admin sets up Team MCP servers for cloud agents in Dashboard → Integrations & MCP, those same servers become available in the team marketplace. Developers can install the approved integrations locally without having to configure servers themselves — no copy-pasting server URLs, no per-machine JSON edits, no drift between what cloud agents can reach and what local IDE sessions can call.

The second change adds org-group access control to team marketplaces. Admins can now restrict marketplace access to specific organization groups under Dashboard → Plugins → Team Marketplaces — separate from the existing SCIM directory group support, which remains available.

Why it matters for AI engineering teams

MCP servers are tool surfaces. Every MCP server a coding agent can call is a capability — and a risk surface. Before this update, the tool routing policy for Cursor agents was effectively set at the individual developer level: whoever edited their MCP config file last determined what tools the agent could call. This made it hard to:

• Enforce approved integrations and block unauthorized ones
• Ensure cloud agents and local IDE sessions call the same set of tools
• Apply different tool access policies to different teams (e.g., frontend vs. security vs. data)
• Audit which MCP servers are active across the organization

Centralized Team MCP distribution through the marketplace flips this. The admin's configuration becomes the source of truth for what tools agents can reach. A developer who installs from the marketplace gets the approved set — not whatever they found on GitHub.

The org-group granularity is the more subtle addition. Previously, a team marketplace applied to an entire Cursor team (or to a SCIM directory group). With org-group support, operators can now scope tool access to sub-team boundaries: the security team gets a hardened MCP set, the ML platform team gets data-access integrations, and neither set bleeds across. This matters for enterprises running Cursor under compliance or data-residency requirements.

The router/operator angle

MCP server governance and model routing governance are converging. The emerging pattern: your operator control plane manages not just which model a request goes to, but which tools that model can call once it arrives. Cursor's Team Marketplace MCP distribution is a step in that direction at the coding-agent layer.

For operators running AI gateways, this creates a practical integration point. When Cursor cloud agents are configured with a specific set of Team MCP servers, those agents' tool calls become predictable and auditable — which makes it easier to build gateway-level policies around them. An agent that can only call pre-approved MCP servers generates a narrower range of outbound requests to your AI routing layer.

Decision framework for teams adopting Team MCP Marketplaces:

• Governance first: define your approved MCP server list before distributing. The marketplace distributes whatever is in the admin config — there's no automatic safety filter.
• Org-group boundaries: use org groups to scope tool access to team-level boundaries. Don't distribute everything to everyone if different teams have different compliance postures.
• Cloud vs. local parity: verify that your Team MCP servers work consistently across cloud agents and local IDE sessions. The marketplace syncs the config, but network reachability from cloud VMs vs. developer machines can differ.
• Audit trail: the centralized config means changes are trackable. Treat changes to the Team MCP registry with the same change-control discipline you'd apply to adding a new provider in your routing gateway.

What TheRouter users should watch or try

If your team uses Cursor with AI gateway routing (e.g., routing Cursor's model requests through TheRouter), centralizing MCP server governance through Team Marketplaces creates a more stable agent profile to route against. Consistent tool surfaces mean more predictable request patterns and cleaner billing attribution.

For teams managing MCP governance at scale, the combination of Cursor's centralized MCP distribution and gateway-level routing policy gives operators two enforcement layers: which model the agent talks to, and which tools it can call. Both should be under operator control — not left to per-seat defaults.

Track the Cursor changelog for upcoming changes to cloud-agent tool policy enforcement, which is likely to follow this governance foundation.