Cursor Plugin Marketplace: Team Setup Guide (3.9, June 2026)

Your team of eight is on Cursor, and every editor is configured differently. One engineer wired in a Linear MCP last month, somebody else copied a Stripe rules file from a Slack thread, and nobody can tell you what the other six are running. Cursor 3.9 (shipped June 22, 2026, per Cursor's changelog) is the first release that gives a team lead a real answer. It adds a Plugin Marketplace, a single Customize page that manages everything at user, team, or workspace scope, a leaderboard that shows what people actually use, and private team plugin repos that now import from GitLab, Bitbucket, and Azure DevOps, not just GitHub.

This is the setup, end to end. Browse the marketplace, add a plugin, scope it to the team, stand up a private team plugin repo, and use the leaderboard to run a monthly trim. Budget 30 to 60 minutes for the first private repo. After that, onboarding a new engineer to your whole config is one click.

What the Customize page actually is

Before 3.9, "customizing Cursor for a team" meant scattered config: a .cursor/rules file in one repo, an MCP server someone added by hand, a skill pasted from a gist. There was no single surface and no way to see what your teammates had set up. The new Customize page collapses that into one screen.

It manages seven component types, each as a chip-style tab, per the classmethod breakdown:

• Plugins -> bundles that package several of the components below into one installable unit
• Skills -> domain-specific prompts and code the agent can discover and run
• Subagents -> specialized agents that run tasks in parallel
• MCPs -> servers connecting Cursor to external tools and data
• Rules -> system-level coding standards and preferences
• Commands -> shareable agent-executable command files
• Hooks -> scripts that observe and control agent behavior

The part that makes this a team tool, not just a settings reshuffle, is the scope selector in the header. Every component lives at one of three levels, per the changelog and the classmethod writeup:

• User -> just you, follows you across projects
• Team -> shared across everyone on your Cursor team seat
• Workspace -> scoped to one project folder

That scope distinction is the whole game for a lead. A rules file that enforces your import order should be team scope so it ships to all eight engineers automatically. A throwaway MCP for one repo's migration stays workspace. Get the scope wrong and you either spam everyone with a personal preference or fail to distribute the standard you meant to enforce.

What a plugin is (and why it matters for distribution)

A plugin is a bundle. Per Cursor's marketplace blog, it combines one or more primitives the agent uses to execute tasks: skills, subagents, MCP servers, hooks, and rules. The launch marketplace ships a curated set from partners including Linear, Figma, Stripe, AWS, Cloudflare, Vercel, Databricks, Snowflake, Amplitude, and Hex.

Why does the bundle matter for a rollout? Adding a raw MCP server gives the agent a connection. A plugin can ship the connection plus the rules that tell the agent how to use it plus a skill that encodes your house pattern. Per the same blog, the Stripe plugin ships Cursor an understanding of how Stripe integrations should be built, not just API access. You distribute intent, not just plumbing.

On disk, a plugin is a Git repository. The structure is small, per Cursor's plugin docs:

my-plugin/
  .cursor-plugin/
    plugin.json        # manifest; only `name` is required
  rules/
  skills/
  agents/
  commands/
  mcp.json             # optional

The manifest is minimal:

{
  "name": "acme-house-rules",
  "description": "Acme import order, error handling, and Linear MCP",
  "version": "1.0.0",
  "author": { "name": "Platform Team" }
}

That name-only requirement is the gotcha worth knowing up front: a valid plugin can be nothing but a rules/ folder. No MCP server, no skill needed to make the bundle legal. For a lot of teams, the first private plugin is exactly that. Your coding standards, packaged so a new hire inherits them on day one.

Step 1: Browse the marketplace and add your first plugin

Open the Agents Window, then find Customize in the left sidebar (per the classmethod walkthrough). The header carries a search field, a Browse Marketplace button, and the scope selector.

1. Click Browse Marketplace.
2. Pick a plugin your team already depends on. If your issues live in Linear, the Linear plugin is the obvious first add.
3. Add it. By default it lands at user scope, live for you and nobody else yet.

Verify it took. On the Customize page, switch the component tab to Plugins and confirm the Linear plugin shows under your user scope. Open the MCPs tab too. A plugin that bundles an MCP server surfaces that server with auth and loading status visible, so a half-configured connection shows up here instead of mid-run.

Step 2: Scope a plugin to the team

Adding at user scope is the test drive. Promoting to team scope is the rollout. With the plugin added and working for you, switch the scope selector in the header to team and add (or re-scope) the plugin there. Now it's part of the shared team config and every seat on your Cursor team inherits it.

The one to get right is the team seat itself. The team marketplace and team-scope distribution are a Cursor Teams plan feature ($40 per user per month, per the pricing page), which lists "Team marketplace for internal rules, skills, and plugins" as a Teams-tier line item. Individual Pro seats can add marketplace plugins for themselves but cannot push a config to a team they don't have. If you're a lead trying to standardize across five-plus engineers, the Teams seat is the thing that makes "shared config" mean anything.

Step 3: Stand up a private team plugin repo

Public marketplace plugins cover the tools everyone uses. Your house config, the internal API MCP, the architecture rules, the migration skill nobody outside the company should see, goes in a private team plugin repo. This is the 30-to-60-minute part, and it's mostly a one-time cost.

The change in 3.9 that makes this broadly usable: team marketplaces now import plugin repositories from GitLab, Bitbucket, or Azure DevOps, on top of GitHub, per the changelog. Before, you were effectively on GitHub or nowhere. Run self-hosted GitLab or Azure DevOps? This is the release that unblocks you.

The flow:

1. Create a Git repo on your provider (GitLab, Bitbucket, Azure DevOps, or GitHub). One repo can hold one plugin or several.

2. Lay out the plugin structure from earlier. Start small. A rules/ folder with your two or three non-negotiable standards is a complete, shippable plugin.

   mkdir -p acme-house-rules/.cursor-plugin acme-house-rules/rules
   cat > acme-house-rules/.cursor-plugin/plugin.json <<'JSON'
   {
     "name": "acme-house-rules",
     "description": "Acme import order, error handling, Linear MCP",
     "version": "1.0.0",
     "author": { "name": "Platform Team" }
   }
   JSON
   # add rules/*.mdc, commit, push to your provider
   git -C acme-house-rules init && git -C acme-house-rules add .
   git -C acme-house-rules commit -m "house rules plugin v1"

3. In Cursor, import the repository as a team marketplace (the Browse Marketplace / team-marketplace import flow on the Customize page). Plugins are indexed at the time of the first import, per the classmethod writeup; you can enable auto-refresh so a push updates the indexed plugin without a manual re-import.

4. Scope the imported plugins to team so they distribute.

The gotcha that bites here: indexing happens at import time. If you push a fix to rules/ and don't have auto-refresh on, the team is still running the old index. When a standard changes and nobody seems to be picking it up, check the refresh setting before you blame the config.

If the plugin you're about to build is really just one function the agent calls during a run, stop. That's an SDK custom tool, not a plugin, and our June 6 guide on SDK custom tools vs MCP servers covers when to write one inline instead of standing up a whole repo.

Step 4: Use the leaderboard to govern, not guess

Distribution is half the job. The other half is knowing what people actually run, and this is where the marketplace leaderboard earns its place. Per the Tessl writeup, it shows the most-used plugins, skills, and MCPs across your team over a 30-day window, including how many times each was used and how many teammates have already added a given plugin. One click adds anything from the leaderboard to your own setup.

What turns this from a popularity chart into a governance tool is the agent-initiated versus human-initiated split. A skill that fires a hundred times a month because the agent reaches for it on its own is load-bearing. A skill that only runs when someone manually triggers it is a candidate for the chopping block. That distinction tells you which parts of your config are doing real work and which are dead weight.

Run it as a monthly review:

1. Open the leaderboard on the first Monday of the month.
2. Anything in the top tier with a high agent-initiated share gets promoted to team scope if it isn't already. That's your team voting with usage.
3. Anything you distributed that's near-zero after 30 days gets cut. If neither the agent nor humans reach for it, it's config debt.
4. Anything popular but still only on individual user setups is a standardization signal: pull it into the team config so new hires inherit it.

Without usage data, plugin sprawl is invisible and permanent. With it, the monthly trim takes ten minutes.

Plugin Canvases: when to reach for each

3.9 also ships Plugin Canvases, prebuilt shared templates a team can open and reuse, per the changelog. Two ship at launch:

• Hex Canvas -> for building data visualizations. Reach for this when the work is exploratory analysis and you want the team starting from the same notebook-style scaffold instead of a blank query.
• Atlassian Canvas -> a realtime view of your Jira issues, projects, and Confluence documents inside Cursor. Reach for this when the agent needs live project context, so it's planning against what's actually in the backlog rather than a stale paste.

Build a custom canvas when neither shipped template matches your recurring starting point. If every sprint begins with the same three-panel setup (your internal dashboard, your runbook, your service map), a custom canvas saves everyone from rebuilding it. Rule of thumb: Hex or Atlassian when your workflow already centers on those tools, custom when your repeated starting state is specific to your org.

Plugin vs MCP server vs SDK custom tool

Three overlapping ways to extend Cursor now coexist, and picking the wrong layer is the most common way teams over-build. Quick decision:

You want to...	Reach for	Scope it lives at
Add a capability that already exists (Linear, Stripe, Figma)	Marketplace plugin	User / team / workspace
Distribute your house standards + connections as one bundle	Private team plugin repo	Team
Connect the agent to your own internal API or data source	Raw MCP server	Per the MCP setup
Give the agent one inline function during a single run	SDK custom tool	Session

The bottom two rows are the subject of our June 6 guide on SDK custom tools vs MCP servers, so we won't re-litigate them. The short version: a marketplace plugin is for anything that already exists, an MCP server is for your internal APIs, and an SDK custom tool is for a one-off function you don't want to stand a server up for. A plugin can contain an MCP server, which is why distribution is cleaner at the plugin layer than wiring servers by hand.

The verdict: who this is for

This release is built for one person: the engineering lead rolling Cursor out to five or more engineers who wants a single shared config people actually use, not a wiki page of setup steps everyone ignores. If that's you, the Customize page plus a private team plugin repo is the cleanest path Cursor has shipped. The first repo costs 30 to 60 minutes; every onboarding after is one click.

Solo developer? Most of this is overhead you don't need. A handful of marketplace plugins at user scope covers you; the team marketplace, leaderboard, and private repo are machinery for a team you don't have. The line is roughly five engineers. Below it, user-scope plugins. Above it, the team config is worth the hour.

The seat math is the catch. Team-scope distribution, the team marketplace, and the leaderboard are Teams-tier features at $40 per user per month. A small setup that just wants marketplace plugins runs fine on Cursor Individual Pro ($20/mo). If you're the lead, the Teams seat is what turns "everyone configures their own editor" into "one config, one click, enforced." Spend the hour on the private repo, wire the leaderboard review into your monthly cadence, and you've replaced config drift with something you can see.