What Are MCP Apps, Connectors, and Plugins? The Ecosystem Explained
You've heard connectors, plugins, MCP Apps, A2A. Nobody explained how they fit together.
You’ve heard connectors, plugins, MCP Apps, A2A. Nobody explained how they fit together. The confusion makes sense: the terminology multiplied faster than anyone documented it. One thing makes all of it click: every layer is built on the same foundation. Once you see the architecture, the vocabulary stops being the obstacle and starts being the map
You added your first MCP server. Then a few more. Then someone mentioned connectors, and you weren’t sure if that was the same thing. Then MCP Apps appeared. Then A2A. And nobody explained how any of it related to what you already had.
That’s not a knowledge gap on your part. That’s what happens when a protocol becomes an ecosystem faster than the documentation can keep up.
I’ve spent the past year deep in this. Tried dozens of servers. Dropped most. Kept eight. Watched the terminology evolve from one word (”MCP”) to an entire vocabulary.
This is the map I wish I’d had at the start.
In this article:
- The vocabulary stopped making sense: how MCP went from one protocol to a layered ecosystem in eighteen months
- “Connectors,” “plugins,” “MCP Apps” are not the same thing: what each layer is and how they relate to the original protocol
- Not all MCP servers are the same type of thing: the three primitives that determine what a server can actually do to your data
- The ecosystem hit 10,000 servers, which makes picking harder, not easier: why most aren’t ready for daily use and the filter that actually works
- A2A is the second protocol you’ll start hearing about: what it is, where it fits, and whether you need to care right now
- Token costs: what to know before your stack grows: how MCP overhead works, what changed recently, and how to keep it manageable
- You have the map, now what?: the three-tier action framework: act now, adjust now, background knowledge for later
Hi, I’m Jenny 👋 I build AI systems and tools, then share how I did it. I run the Practical AI Builder program, for people who already use AI and want to build real things with it. Check it out if that sounds like you.
If you’re new to Build to Launch, welcome! Here’s what you might enjoy:
How Did MCP Become the Standard for AI Tools?
Within eighteen months of launch, MCP went from an Anthropic open-source project to the default standard for AI-to-tool connectivity.
MCP launched on November 25, 2024. Within a year, Cursor, Windsurf, ChatGPT, Google Gemini, and Microsoft Copilot all adopted it. On December 9, 2025, Anthropic donated it to the Agentic AI Foundation under the Linux Foundation. No single company owns it.
The core idea hasn’t changed: a standard way for AI to connect to external tools, so you don’t need custom integration code for every new service.
What changed is everything around it.
MCP is still the plumbing. But the plumbing now runs through a much bigger building, and the building has floors the original spec never described.
Once you know where MCP sits, the terminology above it starts to make sense.
What’s the Difference Between MCP, Connectors, Plugins, and MCP Apps?
All four terms describe different layers of the same foundation, not four competing things.
Most of the confusion comes from one source: the same idea got different names across different products and companies. Here’s the actual architecture.
MCP is the open protocol. How AI connects to external tools. Think of it as the USB-C spec: the standard that makes everything else possible.
Connectors are pre-built MCP servers. When Claude.ai shows you “integrations,” those are connectors. MCP under the hood, already configured. Microsoft Copilot Studio uses the word “connectors” for the exact same concept. Same thing, different brand.
Plugins are packaged bundles. A plugin can include MCP servers, skills (instruction files), and commands, all wrapped into one installable extension. When you install a plugin in Claude, it often activates an MCP server behind the scenes. (If you’ve been confused about the difference between MCPs, plugins, and skills, this breakdown covers exactly that.)
MCP Apps are a new category, launched January 26, 2026. These are tools that return interactive UI: dashboards, forms, charts, visualizations that render directly inside the chat window. Anthropic and OpenAI built the spec together. Claude, ChatGPT, and VS Code all support it. This is genuinely different from a standard MCP server. It’s not just text back from a tool call. It’s a rendered interface inside the conversation.
The architecture in one list:
- MCP is the foundation
- Connectors and servers are built on MCP
- Plugins bundle connectors and skills together
- MCP Apps extend the protocol to return UI, not just text
They don’t compete. They stack.
Knowing the layer tells you what to expect from each type. That matters most when you look at what MCPs can actually do at the protocol level.
What Do MCP Servers Actually Do? The Three Primitives
Most people install MCP servers thinking they’re all the same type of thing: executable functions the AI calls when it needs to take an action.
That’s only one of three things the protocol defines.
Tools are executable functions. The AI takes an action: sends an email, queries a database, posts to social media. Model-driven.
Resources are read-only data. The AI reads information: file contents, API responses, your Notion workspace. Application-driven.
Prompts are reusable templates. Slash commands and structured workflows that bring you into the loop. Can fetch live data.
Why this matters: a resource-only MCP behaves completely differently from a tool-based one.
When you install a server that connects to your database as a resource, the AI is reading, not acting. When it connects as a tool, the AI can write.
Knowing the difference changes how you evaluate and trust what you install. A resource server that reads your calendar needs less vetting than a tool server that can write to your calendar.
Understanding what a server can do at the primitive level is the starting point for the actual selection problem.
Why Are Most MCP Servers Not Worth Installing?
The MCP ecosystem passed 10,000 public servers in April 2026.
The number looks impressive until you check the quality. An audit of 1,847 servers in April 2026 found 52% abandoned (no commits in 90+ days, broken builds, or unreachable endpoints). 31% were lightly maintained. Only 17% met a reasonable production bar.
More than three quarters of what you can install is not ready for daily use.
The selection problem got harder, not easier. Trending lists make it worse. They surface what’s new, not what’s reliable.
The filter that actually works: don’t install from lists. Install from friction. What tab are you switching to manually right now? Find the MCP that eliminates that switch.
If you want a curated starting point, the first MCP roundup still holds. Sixteen servers, four categories, built around real workflow friction. The ecosystem has grown since then, but those picks have held up.
The number will keep growing. Your filter stays the same.
What Is the A2A Protocol and Do You Need to Care?
A2A is a second protocol, not a replacement for MCP. It operates at a different layer.
MCP handles one relationship: AI to tool. A2A handles a different relationship: AI to AI.
Google announced A2A (Agent-to-Agent) on April 9, 2025 at Google Cloud Next. The v1.0 production-ready release shipped March 12, 2026. It’s a standard for how AI agents coordinate with each other: passing tasks, delegating work, reporting back, without a central orchestrator.
Two protocols, two jobs:
- MCP: how an agent connects to tools and data
- A2A: how agents talk to each other
For most builders right now, this is background knowledge. You don’t need to implement A2A today.
But when you hear “multi-agent workflows” or “agent delegation,” A2A is the protocol behind it. If you want to understand the full picture of how AI agents are being built right now, this guide covers the agent framework.
A2A is the protocol you’ll need next. The cost problem is the one worth solving today.
How Much Does Running Too Many MCPs Cost You in Tokens?
Every MCP server you activate loads its tool schemas into your Claude session before you type a single word.
In a mid-sized stack, this consumes 66,000–67,000 tokens before you’ve asked a question. That’s roughly one-third of Claude Sonnet’s context window, gone before the conversation starts.
(Two independent measurements: Scott Spence found 66k tokens in his stack. A developer on r/ClaudeAI measured 67k. The frequently cited “75k” figure from DeployStack is a formula, not a direct measurement: 10 servers × 15 tools × 500 tokens. The real measured figures are lower.)
Update: Anthropic has since shipped lazy loading across all surfaces. As Anthropic researcher Jiquan Ngiam put it: “Claude Chat, Cowork, and Code now load MCP tools on demand.” Tool schemas no longer load upfront by default. The 66–67k measurements reflect the pre-fix state, and the cost problem was real when they were taken. What still loads upfront: MCP server instruction blocks, which vary by server but are smaller than full schema dumps.
The symptoms show up as:
- Sessions that feel slower
- Claude that seems to “know less” in longer conversations
- A bill that goes up without an obvious reason
Two months ago, my own Claude bill hit $1,600 in a month. I wasn’t burning tokens on bad prompts. I was burning them on invisible architecture: MCP servers I’d forgotten were active, loading their schemas into every session I opened.
The fix isn’t removing all your MCPs. It’s being deliberate about which ones are active in which sessions. Not every server needs to run in every context.
The tool that changed this for me is context-mode. It cuts MCP-related token usage 50–90% without changing how your stack behaves. The Claude Code token optimization guide has the full setup and the other architecture decisions that moved the needle.
This is the most actionable section in this article. The next section covers what to prioritize first.
What Should You Actually Do With This Map?
Three tiers: act this week, adjust your current approach, and keep some things as background knowledge for now.
Act this week: the token problem
Open your Claude config and look at which MCP servers are currently active.
Anything you haven’t reached for in 7 days, disconnect it. Not uninstall. Just disconnect. You can reconnect in 30 seconds.
Then install context-mode. It cuts MCP-related token overhead 50–90% without changing how your stack behaves. If you’ve been running 10 or more servers, expect a visible difference in how your sessions feel within a day.
This one change is worth more than most configuration decisions you’ll make this month.
Adjust now: the selection problem
With 52% of the ecosystem abandoned, trending lists will steer you wrong.
When you evaluate a new server, check whether it’s a tool or a resource. Tools can write to your data. Resources can only read. Different trust levels, different vetting required.
The first MCP roundup remains the right starting point for a curated stack. And if you need something that doesn’t exist yet, building your own MCP server is more approachable than most people expect.
Background knowledge: A2A and MCP Apps
You don’t need to build with A2A today. Your AI tools will adopt it before you need to implement it yourself.
If you’re building products (not just using them), watch MCP Apps. The January 2026 spec for interactive UI in chat changes what you can ship. If you’re a user, it’ll just appear.
For everything else (connectors, plugins, terminology), the labels don’t matter. The architecture matters. MCP is the foundation. Everything above it builds on that foundation.
I run 6–8 MCPs. I audit every couple of weeks. Anything I haven’t reached for in a week gets disconnected. That’s it.
What’s the MCP term that’s confused you most? Drop it in the comments. I’ll cover it in the session.
— Jenny
Why Upgrade · Practical AI Builder Program · Claude Hub · Vibe Coding · AI Agents