The plugin is the unit of agency
This series studies the cursor/plugins repository as an official marketplace for agent capabilities. Its focus is not the number of directories in the repository, but the boundary between a capability that an agent can describe and a capability that an agent can safely use. That distinction gives readers a practical way to understand how plugins are found, what they declare, how they change an agent’s behavior, and where responsibility moves to a host runtime, an external provider, or a human reviewer.
The repository matters because it packages several kinds of agency in one ecosystem. Some plugins teach an agent how to work. Some route requests or impose a rule. Some delegate judgment to another agent. Others connect the agent to a browser, a repository, a CRM, a document store, or a financial service. The packaging model is shared, but the consequences are not. A skill that explains how to review a diff and a connector that can update a business record may occupy the same marketplace while requiring very different scrutiny.
The useful idea for holding these cases together is bounded composability. A plugin should add a capability without making the whole system opaque. The marketplace entry should say where the plugin lives. The manifest should say what kind of unit it is. Its components should make behavior, triggers, and connections legible. The runtime should expose what actually happens. The provider should enforce the permissions that matter. When an external action is consequential, the human should still be able to see what will change and decide whether it should happen.
A marketplace, not a bag of prompts
The repository describes each plugin as a standalone directory with its own .cursor-plugin/plugin.json. A central marketplace manifest indexes those directories and gives each one a name, source path, and short description. In the retained checkout, the index contains 112 entries. Most are integrations, while a smaller group covers developer workflows, productivity, and utilities. The count is a snapshot, but the shape is important. This is not one application whose modules happen to be stored together. It is a catalog whose units can be selected and composed according to a task.
The categories also should not be mistaken for risk levels. “Integration” says that a plugin reaches another service. It does not say whether the plugin only reads information, drafts a change, or can cause a live effect. “Developer tool” says that a plugin shapes work inside a repository. It does not say that the workflow is automatic or that its verification is complete. The catalog gives a reader a first classification, not the final answer about what a unit can do.
That distinction changes how the repository should be read. A directory is only a location. A plugin is a declared relationship among metadata, components, and a host. Its manifest can point to skills, agents, rules, hooks, variables, or MCP servers. The marketplace can also express client availability. Some entries require a minimum client version. Others are deliberately hidden from a client with the value never. Discovery is therefore already a small governance layer. It decides which capabilities are visible in which environment before an agent can invoke them.
The repository’s own authoring tools make the same point. The create-plugin workflow asks an author to begin with a concrete use case, target users, and a focused component set. Its review workflow checks that the manifest, component metadata, paths, marketplace entry, and README agree. The desired result is not maximal surface area. It is a plugin whose purpose and boundaries can be understood without reading the whole repository.
The boundary chain
A plugin becomes intelligible when its main interfaces are kept separate. The marketplace index answers, “What can I install?” The manifest answers, “What is this unit and what does it expose?” The components answer, “How should an agent behave around it?” The host runtime answers, “How is that behavior executed here?” An MCP server or local process answers, “What external capability is actually available?” A human reviewer answers, “Is this result or side effect acceptable?”
The arrows describe dependency, not a single execution path. A workflow plugin may stop at the host runtime and never call an external provider. An integration may pass through a provider while using only a small amount of local agent guidance. A human may review an output before any external call, after a draft, or after a result returns. The point is to preserve ownership at each boundary rather than pretend that every plugin follows one identical sequence.
These interfaces are connected, but they do not have the same authority. A marketplace description can summarize a capability without proving that the provider is reachable. A skill can instruct an agent to confirm before a write without becoming an independent authorization system. A manifest can hide a plugin from Cursor without changing what another client or provider permits. The chain is useful precisely because it prevents one layer from standing in for another.
This is also why the repository can contain both workflow plugins and external integrations without losing its identity. A workflow plugin such as pstack changes how an agent investigates, delegates, reviews, and verifies work. A connector such as Google Drive or GitHub gives the agent a path to an external system. The first primarily changes the reasoning process. The second expands the world that the process can affect. Both are plugins because both can be installed, described, and bounded through the same marketplace model.
Why capability needs a boundary
A capability becomes risky when its identity, state, permissions, or effects are hidden. The repository contains several ways to make those dimensions more visible. Skills use explicit frontmatter and describe triggers, workflows, guardrails, and outputs. Hooks register against lifecycle events and persist local state. MCP configurations separate the connection declaration from the prose that explains setup and use. Variables identify the values an administrator or user must provide. Client-version fields state where a plugin should or should not appear.
These mechanisms do not create one universal safety guarantee. They create places where a reader can ask a precise question. Who owns the credential? Is the connection local or remote? Does the agent merely draft a result, or can it commit a live change? What state survives a turn? What verifies the result? Which layer can revoke or narrow access?
Those questions are not abstract checks to apply after the fact. They change how a plugin should be selected. A narrowly scoped workflow may be appropriate when the desired effect is explanation or review. A connector needs more attention when it introduces data access or writes. A plugin that combines a tool with a rule can reduce ambiguity about when the tool belongs in the workflow, but the rule still needs a runtime and provider that respect the intended boundary.
The same reasoning applies to the repository’s internal workflows. Ralph Loop feeds a prompt back into the next turn until a completion promise or iteration limit ends the run. Continual Learning waits for completed turns, elapsed time, and transcript changes before asking for a memory update. Advisor tracks edits and can nudge an agent before it declares work complete. These are useful forms of persistence, but they depend on state files, event payloads, and stop conditions. More autonomy is not free. It must be paid for with more explicit lifecycle control.
What the marketplace lets you judge
The catalog becomes useful when it supports judgment rather than replacing it. For any plugin, a reader can ask five questions.
- How is it found? Check the marketplace entry, source path, client visibility, and version requirement.
- What does it declare? Identify the component mix, variables, and connection type.
- How does it change behavior? Read the skill, rule, agent, or hook that shapes invocation and response.
- Who controls the effect? Separate the host runtime, user identity, provider permissions, and any human confirmation step.
- How is success checked? Look for a terminal result, a re-read, a verifier, a preview, a generated-artifact check, or another observation of the real effect.
The questions form a chain of confidence. A visible catalog entry gives you discoverability. A coherent manifest gives you structural clarity. A readable component gives you an account of intended behavior. A runtime result gives you evidence that the behavior occurred. A provider response and a human review may still be needed to establish what changed in the outside world. Skipping a link in that chain does not always make a plugin unusable, but it makes the source of confidence less clear.
Those questions keep the repository as the subject while avoiding a directory tour. They also expose the series’ central tension. Composability makes it easier to add capability because a new unit can declare a focused surface. The same composability makes it easier to mistake a clean package for a complete guarantee. A well-formed manifest can coexist with an unavailable provider. A polished README can coexist with a remote tool whose schema has changed. A safety rule can be clear while the final authority still belongs to the external service.
The marketplace therefore sells more than access to prompts or connectors. It sells a way to make agent capability selectable and inspectable. Its strongest promise is structural. It can give a capability a name, a place, a declared shape, and a set of checks. It cannot, by repository metadata alone, settle every question about runtime behavior, provider authorization, data handling, or the wisdom of a particular action.
That is the right starting point for reading cursor/plugins. The next question is how the index, manifest, schemas, and CI checks turn this idea of bounded capability into a concrete contract that a client can discover and validate.