Skills and Plugins: The Capability Layer
The Terminology Stack — and Why It Matters
The vocabulary around AI capabilities has fractured across vendors and years. The stack that clarifies everything, bottom to top: (1) APIs — the roads; raw HTTP/JSON interfaces every external service exposes. (2) MCP — the traffic system; the open protocol that standardizes how agents discover and call tools across any API. (3) Connectors / Plugins / Skills — the vehicles; implementation packages that bridge a specific tool to the MCP standard, each carrying its own auth, schema, and contract. (4) LLM (Claude, GPT, Gemini) — the driver; reasons over available skills and decides which to call and when. (5) You — the destination; the business goal that defines success. One-sentence summary: "APIs are the roads. MCP is the traffic system. Connectors are the vehicles. Skills are the pre-planned journeys. Claude is the driver."
Platform Names, One Stack
Every major AI platform uses different words for the same stack layers. Anthropic: Connectors (MCP adapters), Actions (skill calls), Skills (named capability packages). OpenAI: Plugins (legacy, deprecated 2024), GPT Actions (current). Microsoft Copilot: Skills (agent capabilities), Copilot Connectors (MCP adapters). Zapier/Make: Connectors (integration adapters), Integrations (exposed capabilities), Zaps (automation workflows). The practical SE move: when a prospect says "we already have plugins," ask which vendor and which year — they may be describing the same layer under a different name. The unifying frame is always the stack: APIs → MCP → Connector → LLM → You. Vocabulary differs; the architecture does not.
What a Skill Actually Is
A skill is a named, self-describing capability that an agent discovers and calls at runtime. Unlike a raw API call baked into agent code, a skill carries its own contract: name (what to call it), description (what it does — the agent reads this to decide when to use it), input schema (what parameters it needs), and output schema (what it returns). The agent never sees the implementation — only the interface. Two properties matter most for SEs: composability (agents can chain skills — the output of one feeds the input of the next) and governability (you can grant or revoke skill access per agent identity, without changing any agent code). In Google ADK, skills registered in the Agent Registry are discoverable by any agent with the appropriate identity and permission.
The SE Move in a Prospect Conversation
Two scenarios where this vocabulary pays off. Scenario A — prospect architect asks "do your agents support plugins?": do not say yes or no. Say "we use MCP, which is the standardized evolution of the plugin model — here is what that gives you in terms of governance and security." Then connect to Agent Gateway as the policy enforcement layer over all MCP connections. Scenario B — prospect asks "how does an agent know what tools it has access to?": walk through skill discovery — the agent queries the registry for skills it is authorized to use, reads their descriptions to understand what each does, and calls them by name. No hardcoded tool lists. This is the architectural conversation that separates a platform pitch from a product pitch.
Prefer slides, quizzes, and saved progress? Read this lesson in the library — free, no sign-up.