Ship Agent Plugins, Not Naked MCP Servers

Package MCP tools with skills, permissions, and install metadata so hosts get capabilities instead of unfinished adapters.

2488 words

Ship agent plugins, not lone MCP servers

For a few years agent tooling followed a clean arc: connect models to systems (MCP), teach correct usage (skills), then package both as installable units. By mid-2026 that packaging stopped being a vendor slogan and started looking like how teams will distribute capabilities.

What MCP solved

MCP answered “what can the agent connect to?” — typed tools, hosts, and a protocol boundary so Cursor, Claude Desktop, and custom runtimes share the same adapters.

skills/
└── architecture-review/
    ├── SKILL.md
    ├── references/
    │   └── architecture-checklist.md
    └── scripts/
        └── validate_diagram.py

What skills solved

Skills answered “how should the agent perform the work?” — procedures, checklists, and examples that sit above raw tools so the model does not reinvent a workflow every session.

The obvious next gap

Tools without playbooks are dangerous; playbooks without tools are theater. Teams still ship them separately: one repo for servers, another for prompts, a wiki for install steps. Agent plugins collapse that split.

What an agent plugin is

A versioned bundle that declares:

MCP servers (or equivalent tool backends) it needs
Skills / system instructions for correct use
Metadata: permissions, required secrets, host compatibility
An install story a marketplace or CLI can automate

customer-research/
├── plugin.json
├── skills/
│   └── customer-research/
│       ├── SKILL.md
│       └── references/
│           └── report-template.md
└── mcp.json

Why this is more than “another plugin system”

Browser extensions and IDE plugins mostly add UI. Agent plugins add capability: credentials scopes, side-effecting tools, and behavioral policy. That raises the bar for signing, review, and least privilege.

Practical shape

Imagine a “support triage” plugin: a ticketing MCP server, a CRM lookup tool, and a skill that forces citation of ticket IDs before closing. Installing the plugin wires all three instead of three manual setup docs.

my-plugin/
├── plugin.json          # portable
├── skills/              # portable
├── mcp.json             # portable
└── com.vendor.client/   # vendor-specific extension
    └── hooks/

Publish and install

Publishing looks like packaging metadata + artifacts, signing, and pushing to a registry the host trusts. Install should be one command that resolves deps, prompts for secrets, and registers MCP entries — not a checklist of copy-paste JSON.

Portability limits

Plugins are not magically portable across every host. MCP helps on the tool axis; skill formats and permission UIs still differ. Design for a primary host, document gaps, and keep tools protocol-native so a second host can reuse the hard part.

Production mental model

Treat plugins like libraries with runtime side effects:

Pin versions.
Separate discovery from authorization — listing a plugin is not granting prod credentials.
Sandbox tools that can write or spend money.
Log tool calls with plugin id and version for audits.

Discovery ≠ authorization

Marketplaces will show capabilities. Only an org policy gate should attach secrets and allow network. That split prevents “install implies prod access.”

Where MCP and skills land

MCP remains the wire protocol for tools. Skills remain the behavioral layer. Plugins are the distribution unit that ships both with metadata. Do not abandon MCP; wrap it.

What not to do

Do not paste unbounded shell tools into a public plugin. Do not bake customer secrets into the bundle. Do not skip versioning because “it’s just prompts.”

Bigger shift

The market moves from a tool directory to a capability marketplace: curated workflows with explicit risk. Timeline: raw APIs → MCP adapters → skills → signed plugins with policy.

Final take

If you still publish only a naked MCP server, expect support tickets about missing skills and host config. Ship the capability as a plugin: tools, guidance, permissions, and an install path — then treat updates like software releases.

Version plugin manifests the same way you version APIs; breaking tool schemas deserve major bumps.

All articles Send the brief