A clearer route into Claude
Anthropic has opened a developer portal for getting third-party plugins into the Claude directory. The Anthropic announcement, published on 25 September, says builders can submit an integration, follow its review status and publish it after approval. This is a distribution and developer-workflow announcement. It is distinct from the earlier launch of Claude Marketplace, which described how customers discover and buy partner offerings.
A plugin can be a single remote Model Context Protocol, or MCP, connector. Alternatively, a developer can submit a bundle combining MCP servers and Agent Skills through a GitHub repository. Anthropic says Claude Code bundles can also include language-server integrations, commands, hooks and agents. These are different levels of extension, so a team should choose the smallest package that genuinely supports the user task.
The portal is open to developers on paid Claude plans. An integration is not automatically public merely because it was submitted. Anthropic describes validation, safety scanning and review, followed by a separate choice to publish when approved. That sequence matters to organisations planning a launch: they should allow time for remediation and not promise a directory listing on a fixed date before review is complete.
Review is visible to the builder
The new submission flow checks a plugin when it arrives and shows the developer validation and safety-scan results. It also exposes review progress, feedback and recommended changes. This can make problems easier to diagnose than a submission process in which the builder only receives a final yes or no. It does not mean the scan guarantees a plugin is safe in every tenant or workflow.
A connector may be technically valid yet request broader account access than the task needs. A skill may include instructions that produce surprising actions when combined with a particular tool. Developers should test the full permission and failure path: what happens when authentication expires, a server returns malformed data, or an action would change a customer record. Passing portal checks is a starting gate, not an independent security certification.
For enterprises, directory approval and local administrative approval are separate decisions. Teams need to examine OAuth scopes, data residency, service ownership and the user population before making a plugin available internally. An attractive listing can make installation easier, but it should not bypass the controls that apply to other connected applications.
A feedback loop after publication
Anthropic says a published plugin will show installs by product surface and version. Developers can also see listing views and the searches that led users to it. Those metrics can help identify a broken release or a confusing description, and distinguish whether a plugin is difficult to discover or simply not useful once installed.
The figures should be interpreted with care. An install does not prove that a user successfully completed a task, and a search impression does not prove that a listing answered the right need. A practical developer dashboard would pair the portal metrics with privacy-conscious diagnostics, support requests and task-level tests conducted in an authorised environment.
Version-level visibility also makes release discipline more important. If a new bundle changes tool names or authentication behaviour, developers should test an upgrade from an existing installation rather than only a fresh install. A clear change log and rollback plan matter when a plugin becomes part of a team’s everyday work.
MCP extensions widen the experience
Anthropic says Claude supports the latest MCP specification, described in the post as MCP 2.0, including a stateless core. It points to MCP Apps for interactive interfaces inside chat and Enterprise Managed Auth for less repetitive enterprise authorisation. These capabilities can make a plugin more than a plain text tool call, but they add design and trust decisions of their own.
An interactive interface should make the proposed action and its consequences legible. An authentication mechanism should let administrators understand whose authority is being used and when it can be revoked. Developers should resist treating a richer interface as permission to hide the tool’s data sources or side effects from the person using Claude.
Anthropic says one discovery experience will roll out across Claude and Claude Code over coming weeks. Existing skills, connectors and plugins do not need immediate changes, and a connector listing may later be turned into a plugin. That gives maintainers time to decide whether bundling genuinely improves a workflow instead of repackaging an existing connector for its own sake.
What to test before listing
A strong pilot would include the ordinary successful task, an unauthorised request, a network failure and an ambiguous user instruction. Confirm that the plugin explains what it can do, asks for approval before consequential changes and returns a useful error when a connected service is unavailable. Check the same behaviour in the Claude surfaces where the listing will be discoverable.
The portal offers a more complete route from build to discovery to iteration. Its main value is not that every submitted extension becomes trustworthy by default; it is that developers have a more structured way to present, review and improve their work. Users and administrators still need to judge whether a particular plugin deserves access to their data and systems.