What is Cursor Plugins? A catalogue for agent extensions
Cursor Plugins architecture: index, package and execution boundary
Trace how a marketplace entry reaches a manifest and then a client capability
What you will learn
- Read the index
- Read the package manifest
- Mark the trust transition
Before you start
- A disposable client profile
- One selected plugin
- The pinned repository revision
Turn a promising catalogue entry into a repeatable team decision
Key takeaways
- An index entry selects a package.
- A package can contain unlike component types.
- Client behavior is a separate trust boundary.
Read the index
The marketplace schema requires a name and plugin list. Each plugin entry requires a name and source, with optional descriptions and client-version controls.
The index is discovery metadata. It does not itself contain the full implementation of a rule, command, skill, agent, hook or MCP server.
Read the package manifest
The plugin schema has metadata fields and component references. The create-plugin package points to local skills, rules and agents. The GitHub package points to an MCP configuration and a required token variable.
Those two examples show why treating all entries as the same feature obscures real execution boundaries. A local instruction file and a remote HTTP tool can expose very different data.
Mark the trust transition
The client resolves the selected source, loads declared components and may then grant them workspace context or credentials. Review begins before that transition, at the source and manifest, and continues with observed client behavior.
The repository files define package structure; they do not prove the client always sandboxes hooks or prompts. No client internals were audited in this review.
Decision guide
| Criterion | Option A | Option B |
|---|---|---|
| Best when | You need predictable behavior and easy auditing | You need adaptive optimization and have reliable telemetry |
| Main risk | May leave performance on the table | Can become difficult to explain or debug |
Implementation steps
- 1
Trace one marketplace source path.
- 2
Compare its manifest with the files it names.
- 3
Identify which component reads files, executes code or calls a network service.
Copy-ready example
marketplace.json -> plugin source -> plugin.json
plugin.json -> local skills/rules/hooks or remote MCP
client -> workspace and credentialsFrequently asked questions
Where is the marketplace membership defined?
In the root `.cursor-plugin/marketplace.json` at the pinned revision.
Does plugin.json contain all implementation code?
No. It can point to additional local files and MCP configuration.
Sources
- Cursor Plugins / .cursor-plugin/marketplace.jsonSource checked 2026-10-08
- Cursor Plugins / schemas/marketplace.schema.jsonSource checked 2026-10-08
- Cursor Plugins / schemas/plugin.schema.jsonSource checked 2026-10-08
- Cursor Plugins / create-plugin/.cursor-plugin/plugin.jsonSource checked 2026-10-08
- Cursor Plugins / third_party/github/.cursor-plugin/plugin.jsonSource checked 2026-10-08
- Cursor Plugins / third_party/github/mcp.jsonSource checked 2026-10-08