AI plugins arrived in March 2023, when ChatGPT plugins let a chat model browse, run code, and call third-party services. The specific implementation did not last: plugins gave way to GPTs and Actions within a year, and the wider ecosystem converged on the Model Context Protocol for tools, on Agent Skills for procedural instructions, and on app frameworks for anything with a user interface. Plugin is now an umbrella term for the category rather than the name of a format, which is exactly why the word keeps causing confusion in architecture discussions.
Underneath the churn, every version of the idea has the same four parts. A manifest declaring what this thing is. A capability description the model reads to decide whether to invoke it, which is the part that determines whether the plugin ever fires. An authentication story for acting on the user behalf. And an execution boundary defining what it is permitted to touch. Formats change; those four decisions do not.
The taxonomy worth carrying is which mechanism does which job. An MCP server exposes tools and resources over a protocol, discovered and schema-read at runtime, so the model can use an integration nobody wrote client code for. An Agent Skill, defined by a SKILL.md file, supplies instructions and procedural knowledge rather than executable capability, and loads only when the agent decides it applies. OpenAPI-based actions hand the model a REST specification to call directly. Apps wrap a capability in an interface the user can see. Most real assistants use several of these at once, and the common design mistake is reaching for a tool when the thing you needed to supply was knowledge, or the reverse.
It is worth understanding why the first generation stalled, because two of the four causes are still live. Discovery was poor, formats were vendor-specific, descriptions were written for humans rather than for a model choosing between forty options, and there was no trust model at all. Standardization fixed the first two. The other two remain: a plugin description is still the selection interface and still the thing most authors write badly, and an installed plugin is still unsigned text that an agent will treat with roughly the authority of a user instruction.
That last point is the security summary. Every plugin is new attack surface, in three specific ways. Content a plugin returns can carry injected instructions the model then follows, which is indirect prompt injection with a delivery mechanism. OAuth scopes granted at install time are usually far broader than any individual call needs. And the agent frequently holds credentials the requesting user does not, which is the confused deputy problem in its classic form. There is also a quieter cost: every installed plugin description occupies context on every single turn, so forty installed plugins is a standing token tax whether or not any of them are used.
The limit of the whole category is worth naming, because it is a different axis than capability. Plugins give an assistant things it can do. They do not give it continuity. A booking plugin knows how to reserve a flight and does not know that you always take an aisle seat, fly out of a specific airport, and refuse red-eyes. That gap is not a missing plugin; it is a missing layer.
Why It Matters
Plugin architecture decides what an assistant can actually accomplish, and plugin descriptions decide whether it ever tries. Teams building extensions consistently underinvest in the description and then conclude the model is unreliable, when the model simply never selected their tool. Teams installing extensions consistently underinvest in scoping and then discover an agent had standing access to far more than any task required. Both mistakes are cheap to avoid and expensive to find in production.
Example
A company builds an MCP server exposing its CRM and describes it as Comprehensive CRM integration providing access to accounts, contacts, opportunities and related records. The agent almost never calls it, because no incoming request resembles that sentence. They split it into four narrowly named tools with descriptions written around triggers rather than contents, such as use when the user asks about a specific customer account status or renewal date. Same backend, same data, and invocation rate on relevant tasks goes from occasional to consistent, while each response returns six fields instead of forty and costs a fraction of the context.