Feature request for product/service
Marketplace
Plugin Advisor: Scope Classification, Detection Hints, and Repo-Aware Recommendations
The Cursor plugin marketplace has quietly become powerful enough to shape how people work, but the discovery model still feels stuck in an earlier era of software catalogs: browse a long list, click into each plugin, read generic descriptions, and guess whether any of them actually matter for the repo in front of you. That gap is small when there are only a few plugins. It becomes real friction when there are 24+ options, many of which are excellent but only in the right context. A developer inside a Python or FastAPI codebase should not have to manually figure out that Sentry, Hugging Face, Tavily, or Linear are relevant while Figma, BrowserStack, or tldraw may be less immediately useful. The marketplace should do more of that thinking for them.
The core problem is not a lack of plugins. It is a lack of fit signals. Today, most plugin detail pages answer a basic “what does this plugin do?” question, but they do not address the higher-value questions users actually have when deciding whether to install something: Is this useful to me personally in almost every repo? Is it only valuable if this project uses a certain stack, service, or workflow? Is this a global productivity plugin, a repo-specific integration, or something that matters at the team or workspace level? Without those answers, discovery becomes a slow, trial-and-error process.
That is why the marketplace would benefit from a recommendation system built around scope and relevance. Each plugin should clearly communicate whether it is best understood at the user level, project level, or global/workspace level. Some plugins are broadly useful across the board because they improve research quality, documentation access, agent discipline, or coding workflows in a stack-agnostic way. Others only become truly valuable when a repo is already using a specific product, framework, SDK, or deployment pattern. The marketplace should reflect that difference rather than flattening everything into a single generic description field.
The most useful version of this idea would go beyond better copy and turn plugin discovery into a contextual recommendation experience. Imagine opening the marketplace from an active repo and seeing a section like Recommended for this project. Cursor could infer likely relevance from lightweight signals such as dependency files, config files, framework usage, environment variable names, or common service markers. A repo with sentry.properties, SENTRY_DSN, or @sentry/* dependencies could surface the Sentry plugin. A project with transformers, datasets, or Hugging Face tokens could surface Hugging Face skills. A repo with Figma-heavy frontend work, BrowserStack configs, Linear SDK usage, or Notion automation hooks could be matched accordingly. This does not need to be invasive or magical. It just needs to be helpful.
Just as important, the plugin details page itself should explain why a plugin is being recommended. A good plugin page should not only say what the plugin does, but also show:
- whether the plugin is best for individual workflows, a specific repo, or broad workspace use
- what kinds of projects benefit most from it
- what frameworks, services, or repo patterns usually make it relevant
- whether the current repository appears to match those signals
That last part is especially important. The marketplace should feel aware of context, not just aware of inventory. Users should be able to tell at a glance whether a plugin is something to install once and use everywhere, something to enable only when a repo uses a certain service, or something better suited to a team-wide workflow. That distinction would make the marketplace feel dramatically smarter without making it more complicated.
This would help more than just end users. Plugin authors would benefit too. Right now, authors have one main shot to describe their plugin, and they are forced to compress too much into a short paragraph. If the marketplace had structured fields for scope, ideal project types, related frameworks, and relevance hints, plugin authors could present their work much more honestly and effectively. Instead of competing for attention with vague “works with AI agents” language, they could clearly say: this is useful in any repo, this is useful mostly in frontend product teams, or this is useful only when your stack already includes a certain service. Better positioning would mean better installs, fewer misfires, and fewer disappointed users.
There is also a strong ecosystem reason to build this now. As plugin catalogs grow, marketplaces stop being simple lists and start becoming decision engines. The next wave of great developer marketplaces will not win by having the most entries. They will win by helping users discover the most relevant entry at the exact moment it becomes useful. That is especially true in an AI-native workflow, where the question is not just “what exists?” but “what should I enable for the repo I am in right now?” Cursor is unusually well-positioned to answer that question because it already has the
workspace context, the plugin metadata, and the user intent in the same surface.
In short, this feature would make plugin discovery faster, smarter, and more trustworthy. It would reduce trial-and-error installs, help new users understand plugin fit more quickly, give advanced users better signals for when a plugin belongs at the global scale versus the repo scale, and give plugin authors a better way to express where their tools actually shine. The marketplace does not just need more plugins. It needs better judgment. A recommendation system that understands scope, repo relevance, and project fit would be a meaningful step in that direction.
