The Product Hunt for AI Plugins

AI agent plugins are getting a common package format. Finding the right one is still a separate problem.

Agent Plugins 1.0.0 defines a vendor-neutral way to package reusable agent components. A conforming plugin has a root plugin.json manifest and can include Agent Skills under skills/ plus MCP server configuration in mcp.json. The specification gives compatible clients a predictable structure to validate and load.

That matters because plugin authors have been rebuilding the same extension for different clients. Google described the problem directly when it joined the Agent Plugins technical steering group in August 2026: the underlying skill or MCP server may be portable, while the wrapper, manifest, and configuration around it differ by client. AWS made the same case when it announced support for the standard.

Agent Plugins 1.0 reduces that packaging tax. It does not create a universal app store.

What Agent Plugins 1.0 actually standardizes

The 1.0 specification intentionally keeps the portable core small. It defines two component types:

• Agent Skills. Skills live under skills/, with each skill using the external Agent Skills specification and a SKILL.md file.
• MCP servers. MCP connections are declared in a root mcp.json file. The format supports stdio, Streamable HTTP, and legacy HTTP+SSE connection definitions, while the Model Context Protocol remains authoritative for MCP behavior itself.

The package also includes plugin.json, which identifies the plugin, its version, description, author, repository, license, keywords, and the Agent Plugins schema version it targets.

This creates a useful interoperability floor. A plugin can put portable pieces in known locations instead of inventing a new directory structure for every compatible client.

What the standard deliberately leaves out

The most important detail for marketplaces is what Agent Plugins does not standardize.

The official specification leaves distribution, installation, enablement, updates, permissions, user experience, and client-specific behavior to clients and other ecosystem layers. It also does not define a universal reputation system, ranking model, review system, or discovery protocol.

That separation is sensible. Packaging and discovery are different jobs.

A portable plugin format answers: What is this package, and where are its portable components?

A discovery layer has to answer different questions:

• What plugins exist for the task I am trying to complete?
• Which clients or environments can actually use them?
• Where is the source repository?
• Who maintains the plugin?
• When was it last updated?
• What skills and MCP servers does it contain?
• What permissions or runtime behavior should I inspect before installing it?
• Is there enough evidence to trust the listing?

This is why plugin marketplaces, registries, curated directories, and client-native catalogs still matter even when packaging converges.

The next problem is discovery

Once plugins become easier to move across clients, the number of useful packages can grow faster than any one client catalog can organize them.

That creates a familiar software-discovery problem. Developers need searchable metadata, source links, categories, compatibility information, and enough context to compare alternatives without opening dozens of repositories.

HOL is building HOL Plugins as one public discovery surface for this ecosystem. The goal is straightforward: make it easier to find plugins, skills, and MCP-based tools across coding-agent ecosystems from one place.

A marketplace listing should not be treated as proof that a plugin is safe, standards-conformant, maintained, or appropriate for a particular environment. Those are separate claims that require evidence. Discovery should make that evidence easier to inspect, not blur the distinction.

How to evaluate an AI agent plugin

Before installing a plugin from any marketplace or directory, check the underlying package and project rather than relying on a listing title alone.

1. Open the source repository

Confirm that the listing points to the expected repository and maintainer. Look at recent commits, releases, open issues, and whether the project explains how updates are published.

2. Inspect the manifest

For Agent Plugins 1.0 packages, the root plugin.json is the starting point. Check the declared schema version, repository, license, description, and author metadata. A familiar package name is not a substitute for verifying the source.

3. Review skills as executable guidance

A SKILL.md file is not just documentation. It can shape how an agent approaches a task and may reference scripts, assets, or other bundled files. Read it with the same care you would give code that influences an automated workflow.

4. Review MCP configuration

If the plugin includes mcp.json, inspect each server entry. Determine whether it launches a local process or connects to a remote endpoint, what arguments and environment values it uses, and whether that behavior matches what you expect from the plugin.

The Agent Plugins specification explicitly says configured environment values and headers are visible package data, not a portable secret mechanism. Credentials should not be embedded there.

5. Separate portability from compatibility

A package can follow a portable format without every client supporting every component. Agent Plugins 1.0 allows incremental adoption, so a client can support skills without supporting MCP servers, or support only particular MCP transports.

Check the client you actually use.

6. Treat installation as a trust decision

A standard package format does not automatically sandbox a plugin. The specification defines package-path containment and failure boundaries, but it does not claim that plugin subprocesses are fully sandboxed. Installation can still introduce code, instructions, network connections, and tools into an agent environment.

That makes provenance and review especially important for plugins that can execute commands, access repositories, connect to internal services, or invoke external APIs.

Portability should make marketplaces better

Portable packaging can improve discovery because marketplaces no longer need to normalize every client-specific wrapper before presenting basic plugin metadata.

Over time, that should make it easier to build better search, filters, compatibility views, provenance checks, and comparison tools. It also gives plugin authors a clearer path to publish once and be discoverable across more than one ecosystem.

But the best outcome is not one giant catalog that declares everything trustworthy. It is an ecosystem where package structure is portable, discovery is open, and claims about compatibility, maintenance, and security stay tied to evidence.

If you are exploring the ecosystem, browse HOL Plugins. If you are building a portable package, start with the Agent Plugins 1.0 specification and the official launch material from Google and AWS.