That is why I use the phrase everything becomes a plugin. I do not mean that every capability will share one package format. I mean that useful business capabilities are becoming modular, discoverable, and callable through Skills, MCP servers, APIs, platform plugins, and workflows.

The exciting part is composition. The dangerous part is assuming that discoverable means trustworthy.

Popularity is discovery, not evidence

Stars, installs, likes, and author descriptions are helpful when deciding what to inspect. They do not answer the questions that matter during a real task:

• Which exact version was tested?
• In which environment did it run?
• What could it read or write?
• Where did the data go?
• What acceptance criteria were used?
• Which failures or human interventions occurred?
• Is the evidence still current?

A popular Skill may fail on a conflicted meeting note. An MCP server may connect successfully but produce an unusable business result. A low-permission tool may still be inaccurate, while an effective tool may request more access than the task justifies.

Popularity, security observations, compatibility, and task effectiveness are different axes. Collapsing them into one score hides risk.

A minimal evidence contract

For every agent capability, I want four evidence blocks.

1. Provenance and version

Record the maintainer, source, revision or package version, content digest when practical, and license or redistribution basis. If the identity of the evaluated artifact is ambiguous, a passing result becomes meaningless as soon as the project changes.

2. Permissions and data destinations

State what the capability can read, write, execute, install, or send over the network. Name external services that receive data and any additional account or administrator approval required.

Documentation can describe requested permissions, but it cannot enforce them. Actual authorization belongs to the host, the service, and the user.

3. Task, environment, and result

“Works” is not a test report. Record the task definition, input boundary, acceptance criteria, host and model versions, dependencies, sample size, human interventions, time basis, cost basis, and every observed failure.

Keep the states separate:

• static validation;
• installation;
• successful execution;
• target-side readback;
• human acceptance.

A green checkmark should never silently merge these stages.

4. Recency and invalidation

Every result needs a date and an invalidation rule. A change in the Skill, MCP server, model, host, dependency, permission scope, or test scenario may require a retest.

This matters especially for enterprise delivery teams. They are not selecting a tool once; they are maintaining a changing system.

Security and usefulness require different tests

A static scan can identify some suspicious patterns, but it cannot prove universal safety. A sandboxed run can show behavior under specific controls, but it cannot prove the absence of hidden behavior elsewhere.

Likewise, a task test can show that a defined workflow met predetermined criteria on a defined sample. It does not become a universal quality score.

The useful discipline is simple: name the evidence type, preserve its boundary, and leave unknowns visible.

A first-party implementation experiment

I created the open-source Agent Catalog Seed to make this evidence model concrete. It contains a versioned schema for provenance, requested permissions, compatibility, evaluation status, conflicts, and rights; a synthetic non-installable example; an evaluation-report template that retains failures and unknowns; and governance guidance.

It is an open-source starting point, not a live marketplace. The public Skill has passed static format validation, but it has not received an independent real-edit evaluation or broad cross-host compatibility testing. There is no independent security certification, verified platform-partner program, real-user rating system, or validated commercial model.

Those gaps are not marketing footnotes. They are exactly what an evidence system should keep visible.

What this enables

An evidence-aware registry can do more than list links. It can help teams:

• monitor versions of the capabilities they rely on;
• rerun customer-task regression checks after changes;
• maintain allowlists with owners and review status;
• distinguish compatibility from effectiveness;
• flag when an old result has become “retest required.”

The long-term vision is that everything becomes callable. The near-term discipline is less glamorous: identify the exact artifact, state the permissions, test a defined task, preserve failures, and repeat when the system changes.

That is how a plugin ecosystem becomes useful before it becomes large.

Disclosure: I initiated and maintain Agent Catalog Seed. This article is a first-party project update and received AI assistance in drafting and editing. I reviewed the final claims. No sponsor paid for this article.