If you write code for a living in 2026, your editor is no longer just an editor — it is an agent runtime. The Cursor plugins open-source repository, Cursor’s official home for agent plugins, has picked up more than 13,500 GitHub stars and over a thousand forks since it opened, and it quietly tells you where the whole AI-IDE market is heading: the model is becoming a commodity, and the ecosystem around it is becoming the product. In this guide we unpack what the repository actually contains, how its plugin system works, why it is trending, and what it means for your team if you build software for clients or your own business.
What the Cursor plugins open-source repository actually is
The cursor/plugins repository is Cursor’s official, public home for the plugins that extend the Cursor coding agent. Its own one-line description says it plainly: “Cursor plugin specification and official plugins.” Each plugin lives as a standalone directory at the repository root, carries its own .cursor-plugin/plugin.json manifest, and the root-level .cursor-plugin/marketplace.json file lists everything available. The project is MIT-licensed, written primarily in TypeScript, and it was still being actively pushed as of October 2026 — this is a living marketplace, not a press-release dump.
Why does this matter more than a normal extensions marketplace? Because a Cursor plugin is not a toolbar button. It is a bundle of instructions, skills, rules, slash commands, and MCP server definitions that teach the agent how to do new work: how to review your branches, how to run your test suite, how to talk to your Salesforce org or your Shopify store. You are not installing a feature — you are installing competence.
What’s inside: 109 plugins across four categories
We went through the repository’s plugin table line by line. Here is the honest inventory: 109 plugins sorted into four categories — 83 integrations, 16 developer-tools plugins, 8 productivity plugins, and 1 utility. Cursor itself authors the vast majority (102), with a handful of community contributions from developers like Eric Zakariasson, Dylan Gattey, and Lauren Tan.
The developer-tools core
The sixteen developer-tools plugins are where the most interesting engineering thinking lives. Highlights include:
- cursor-sdk — build apps, scripts, and automations on the TypeScript SDK.
- origin-apps — skills for building on the Cursor Origin API, including a planner for porting an existing GitHub App.
- orchestrate — fan large tasks out across parallel cloud agents with planners, workers, verifiers, and structured handoffs.
- ralph-loop — iterative self-referential AI loops using the Ralph Wiggum technique, a pattern serious agent builders will recognize.
- thermos — deep security and correctness audits with harsh code-quality rubrics, parallel subagents, and optional merge-ready PR flows.
- create-plugin — the official scaffolder for building and validating new marketplace-ready plugins.
- advisor — consult a stronger model before major decisions, when stuck, and before declaring done.
- cli-for-agent — patterns for designing CLIs that coding agents can run reliably: flags, examples in help output, idempotency, dry-run.
The 83 integrations
The integration category is the real story. These are third-party plugins that wire the agent into the business software stack: Gmail, Google Drive, Calendar, Docs, Sheets, Slides, Salesforce, HubSpot, Intercom, Slack and Microsoft Teams, Zoom, Notion-style docs, plus heavy-hitters like GitHub, Playwright, Semrush, Ahrefs, Shopify, Meta Ads, Google Ads, QuickBooks Online, Xero, Gusto, Workday, and — worth noting — trading platforms like Robinhood, Coinbase, Webull, Interactive Brokers, and eToro. There is even a Tailscale plugin that lets the agent reach MCP servers on your private network. The pattern is clear: Cursor wants its agent to be able to do the job, not just write the code for the job.
How Cursor plugins actually work under the hood
The repository doubles as a public specification, which is genuinely useful: you can read exactly what a well-formed plugin looks like. Every plugin follows the same anatomy:
.cursor-plugin/plugin.json— the manifest: name, description, author, and which components the plugin ships.skills/— agent skills asSKILL.mdfiles with frontmatter, the same pattern Anthropic standardized for Claude Code. Skills are how the agent learns a repeatable procedure.rules/— Cursor rules as.mdcfiles: persistent instructions the agent follows automatically in the right context.mcp.json— MCP server definitions, so the plugin can expose live tools (API calls, browser actions, database queries) the agent can call.- README.md, CHANGELOG.md, LICENSE — documentation and versioning, the way any serious package should ship.
Installing one is conversational. The create-plugin plugin’s own README documents the pattern:
/add-plugin create-plugin
You invoke /add-plugin with the plugin’s name, and Cursor fetches the plugin bundle — skills, rules, commands, and MCP wiring — straight into your agent session. Building your own follows the same flow: the create-plugin skill scaffolds the directory, and a review-plugin-submission skill runs pre-submission quality checks against marketplace expectations before you ship. That submission-review step is a small detail that says a lot about where this is going: curated marketplace, quality gates, and a plugin economy with real standards.
Why it’s trending: the plugin economy is the new moat
Here is the angle that matters if you run a business. Three years ago the IDE wars were about autocomplete quality. Two years ago they were about which model you shipped with. In 2026, the frontier models are close enough in quality that no single one is a durable advantage — and Cursor knows it. What Cursor is doing with this repository is what every platform company does when the core technology commoditizes: it is moving the moat to the ecosystem.
Think about the economics from the developer’s side. Every plugin you install makes the agent more useful inside your specific workflow — your CRM, your ad accounts, your finance stack, your team rituals. That is switching cost, and it compounds: the more plugins a team adopts, the more expensive it becomes to move to a competing IDE, even if that IDE has a marginally better model. For Cursor, 109 official plugins (and counting) are a distribution flywheel.
For everyone else, it is a signal about where the software economy is heading. The SaaS companies rushing to ship plugins — Salesforce, HubSpot, Shopify, Semrush — are not doing it for fun. They have realized that the next great distribution channel is not the app store or the Chrome Web Store; it is the agent. If your customer lives in their IDE eight hours a day, and the agent can now operate your product on their behalf, the plugin is your storefront. Expect every serious B2B SaaS product to have a Cursor plugin within a year, and expect the same pattern to be copied for every other agent platform. The agent-plugin economy is becoming as real as the mobile app economy was in 2010.
From our experience: what matters and where it breaks
We have spent nine-plus years building software for clients across web, mobile, and automation, and we have watched enough “revolutionary” tooling waves to have opinions. Here is our honest read on this one.
Start with the workflow plugins, not the fun ones
The flashy draw is the 83 integrations — “the agent can check my Robinhood portfolio!” — but the highest-ROI plugins for a dev team are the boring ones: cursor-team-kit for standardizing CI and code-review workflows, pr-review-canvas for diff review, agent-compatibility for auditing that your docs match reality. In our experience, the teams that get the most out of coding agents are the ones that encode their process into the agent, not the ones that collect the most integrations. One well-built team plugin beats ten shiny ones you never configure.
Pin your versions and expect churn
This repository was actively pushed on the day we researched it, and that is both the good news and the warning. A fast-moving plugin spec means APIs, skill formats, and manifest requirements will change under you. If you build internal plugins for a client team, treat them like any other dependency: pin the version you validated, keep a changelog, and re-validate on updates. We have seen agent workflows silently degrade when an upstream skill changes its assumptions — debugging “the agent got dumber” is nobody’s idea of a productive afternoon.
When not to reach for a plugin
Not every integration deserves plugin status. If a task is a one-off script — a data migration, a bulk rename, a CSV cleanup — writing a plugin for it is over-engineering; a good prompt and a shell script will do. Plugins earn their keep on repeatable work: the weekly report pull, the standard PR review ritual, the onboarding checklist your team runs for every new hire. If you would not write a runbook for it, do not write a plugin for it.
A note on responsible use: plugins hold the keys
This deserves its own section because it is the part everyone skips. Many of these plugins authenticate against production systems: your email, your CRM, your ad accounts, your brokerage. Some — Coinbase, Robinhood, eToro — can preview and place trades. A plugin is executable code with credentials, and installing one deserves the same scrutiny you would give any third-party dependency: check the author, read the skill files (they are plain markdown — there is no excuse not to), understand exactly which permissions the MCP server requests, and prefer official authors for anything that touches money or customer data.
Our agency rule of thumb, which we recommend to clients: start every new plugin in read-only mode where the integration supports it, use dedicated service accounts rather than personal credentials, and never grant a brand-new plugin write access to a production system on day one. If you need help designing safe workflow automation around AI agents — with approval gates and audit trails — that is exactly the kind of architecture we build.
Getting started with the Cursor plugins repository
- 1. Browse the catalog. Open the repository and scan the plugin table for the tools your team already pays for — there is a good chance your CRM, docs, or analytics platform is already there.
- 2. Install one low-risk plugin first. In Cursor, run
/add-plugin <name>with something read-only, like a search or reporting plugin, and watch how the agent uses its new skills for a week. - 3. Read the skill files. Before installing anything with credentials, open the plugin’s
skills/directory and skim theSKILL.mdfiles. They are short, and they tell you exactly what the agent is being taught to do. - 4. Scaffold your own. Run
/add-plugin create-plugin, then use thecreate-pluginskill to scaffold a plugin for your team’s most repeated internal workflow — the onboarding checklist, the release ritual, the standard code-review pass. - 5. Run the quality gate before you share. The
review-plugin-submissionskill checks your plugin against marketplace expectations. Use it even for internal-only plugins; future-you will be grateful.
Frequently asked questions
Is the Cursor plugins repository free to use?
Yes. The repository is MIT-licensed, so you can read, fork, and build on the plugin specification freely. The plugins themselves install inside Cursor, which is a paid product, and individual third-party integrations may require subscriptions to the underlying services (Salesforce, Semrush, and the like).
How do I install a Cursor plugin?
Inside Cursor, run the /add-plugin command followed by the plugin’s name — for example, /add-plugin create-plugin. Cursor fetches the plugin’s skills, rules, commands, and MCP server definitions into your agent session. Each plugin’s README documents any extra setup, such as API keys.
Can I build my own Cursor plugin?
Yes — that is half the point of the repository being open source. Install the create-plugin plugin, which scaffolds a new plugin directory with the manifest, skill/rule/command structure, and repository wiring, then run its review-plugin-submission quality check before sharing or submitting it. MIT licensing means you can also fork existing plugins and adapt them to your team’s stack.
How many plugins are in the repository?
At the time of writing, the repository lists 109 plugins: 83 third-party integrations, 16 developer-tools plugins, 8 productivity plugins, and 1 utility. Cursor authors the overwhelming majority, with a small but growing set of community contributions. The catalog is actively expanding, so treat any number you read as a snapshot.
Are Cursor plugins safe to install?
Mostly, but with the same caveats as any third-party code: plugins can run commands and hold API credentials, and several integrations can take real-world actions like placing trades or sending messages. Prefer official authors, read the skill files before installing, start with read-only permissions, and use dedicated service accounts for anything that touches production systems or money.
The plugin economy is not coming — it is here, it is open source, and it has 13,500 stars to prove it. Whether you are a solo developer or an agency shipping for clients, the teams that win the next phase of the AI-IDE race will be the ones that treat their agent’s plugins the way they treat their dependencies: curated, versioned, and chosen with intent. If you want a partner who builds that kind of disciplined AI workflow — from custom API integrations to full agent automation — talk to our team, or browse our AI tools directory for more tools we have vetted in real projects.