In brief: MCP server is the engineering term β a JSON-RPC 2.0 process exposing tools, resources, and prompts. MCP app is the product term β the user-installable artifact built on top. Connector is what Claude calls an installed MCP app inside its product. Plugin, integration, and skill are inherited or vendor-specific terms that mean different things in different rooms. Use MCP app as your umbrella term, MCP server for engineering, and the host client's preferred word (connector, Custom GPT app, etc.) on that client's surface.
An MCP app is the user-installable product built on top of an MCP server. An MCP server is the running process implementing the Model Context Protocol over JSON-RPC 2.0. A connector is what Claude calls an installed MCP app inside its product. These three terms refer to different layers of the same system, and confusing them is the most common cause of stalled MCP roadmaps in 2026. The Model Context Protocol is just over eighteen months old as of this writing β Anthropic introduced it in November 2024 β and the industry has not yet agreed on what to call the things being built on top of it.
Walk into any product meeting on this topic and you will hear, in roughly this order: MCP server, connector, integration, plugin, app, skill, tool, extension, and increasingly agent used loosely for any of the above. None of these are wrong. Several are technically correct in different layers. But the ambiguity is not free. Roadmaps stall on vocabulary disagreements that look like product disagreements. RFPs go in circles because each side means something different by the same word. Partner kickoff meetings spend the first hour establishing what the product is actually called.
Key Signal
The cost of mixed MCP terminology is paid in calendar weeks. We have watched a fifteen-person product team take six weeks to converge on internal vocabulary for an MCP app they had been building for three months. Vocabulary precedes strategy β companies without shared internal language for the artifact they are building produce inconsistent positioning, fragmented marketing, and confused engineering specs.
This guide lays out the three layers of MCP-powered software, surveys the eight terms in circulation, and proposes a working vocabulary product teams can use until the market settles. The rest of our MCP guide series uses this vocabulary throughout.
The Three Layers of MCP-Powered Software
Most of the confusion resolves once you see that MCP-powered software is at least three distinct objects, and the words people use are referring to different ones.
The first layer is the protocol implementation β the running MCP server. A process, a binary, a hosted endpoint. It implements the MCP spec, exposes a set of capabilities, and speaks the wire protocol the AI client expects. Engineers care about this layer.
The second layer is the capability surface β the set of tools, resources, and prompts the server exposes. create_invoice, search_inventory, book_meeting. This is where product design lives: what the agent can do on the user's behalf, with what parameters, returning what shape of data. Designers care about this layer.
The third layer is the user-installable experience β the artifact a buyer adds to their AI client and calls something. Branding, distribution, monetization, the marketplace listing, the support channel. Marketing and product care about this layer.
MCP server is a layer-one word. Tool, resource, and prompt are layer-two words. Connector, plugin, app, and integration are all layer-three words, competing for the same job: name the thing the user installs.
What MCP is technically
Before going deeper into terminology, it helps to anchor on what MCP actually is at layer one. MCP is a JSON-RPC 2.0βbased protocol introduced by Anthropic in November 2024 and open-sourced at modelcontextprotocol.io. An MCP session begins with a capabilities negotiation between client and server, proceeds with the server advertising what it can do via three primitive types, and continues for the duration of the session with the client invoking server operations as the agent decides.
The three MCP primitives are:
-
Tools β operations the agent can invoke. Each tool has a
name, adescription(read by the agent at runtime to decide whether to invoke it), and aninputSchema(a JSON Schema specifying parameters). - Resources β data the agent can read. Each resource has a URI, a name, a description, and a MIME type.
- Prompts β templated user-facing prompts the server can offer. Used much less widely than tools and resources in practice.
MCP supports three transports: stdio (process-to-process, for local servers), SSE (Server-Sent Events over HTTP), and streamable HTTP (the newer remote transport that consolidated SSE's responsibilities). For remote MCP servers, the spec includes an OAuth 2.1 + PKCE authorization flow with Dynamic Client Registration and authorization-server metadata discovery.
Once the layers are visible, vocabulary arguments resolve into a question of which layer the speaker means. The engineer saying MCP server is not wrong; they are referring to layer one. The marketer saying connector is not wrong; they are referring to layer three through Anthropic's chosen vocabulary. Both can be right; both can also be the wrong word for the room. The discipline is knowing which.
The Eight MCP-Related Terms in Circulation
Eight terms are in active use as of mid-2026, and they refer to different things at different layers of the system.
| Term | Layer | Meaning | When to use it |
|---|---|---|---|
| MCP server | Engineering | Process implementing the MCP spec (JSON-RPC 2.0) | Architecture diagrams, technical docs, contracts |
| MCP app | Product (umbrella) | User-installable artifact built on an MCP server | Roadmaps, investor decks, cross-client positioning |
| Connector | Product (Claude-specific) | Anthropic's term for an installed MCP app in Claude | Inside Claude marketing and docs |
| Plugin | Product (legacy) | Inherited from ChatGPT Plugins (2023); pre-MCP framework | Avoid in new copy β implies older, more constrained model |
| Integration | Product (generic) | Generic enterprise term for cross-system connection | Operationally clear in procurement; loses MCP's autonomy signal |
| App | Product (multi-vendor) | Used in ChatGPT App Store, Custom GPTs, Claude apps | When the host client uses it |
| Tool | Capability primitive | Individual operation an MCP server exposes (create_invoice) |
Engineering docs and product specs |
| Resource | Capability primitive | Data item an MCP server exposes (a document, a record) | Engineering docs |
| Prompt | Capability primitive | Templated user-facing prompt the server offers | Engineering docs |
| Skill | Collided | Claude's separate concept ("Skills") that is not MCP servers | Avoid in mixed-vendor rooms |
| Extension / add-on | Product (legacy) | Browser-era inheritance; underclaims agent autonomy | Avoid β undersells the product |
A short tour of the layer-three terms
The marketing decisions live at layer three, so this is where most of the language churn is felt.
Connector is Anthropic's user-facing term inside Claude. It names the relationship β you connect a thing, then Claude can use it β but other clients do not use it, and copy written entirely in connector reads as Claude-specific the moment it is read on another surface.
App is gaining ground. Custom GPTs are sometimes called apps; Claude has begun using Claude apps for installable connector experiences. App carries the right mental model β something installable, that does a job. The cost is overloading an already-overloaded word.
Plugin is inherited from the ChatGPT Plugins era of 2023. Still in casual use, but it implies an older, more constrained model in which a third party hooks into a host. MCP-powered software is often neither.
Integration is the generic enterprise term. Operationally clear inside procurement; flattens the distinction between MCP and the previous generation of webhook-and-Zapier integrations, which is a feature for fast procurement conversations and a bug for accurate strategic positioning.
Skill is collided with Claude's existing concept of Skills, which are not MCP servers. Avoid in mixed-vendor rooms unless you intend to spend ten minutes disambiguating.
Extension and add-on underclaim the autonomy a modern MCP server has when wired into an agent.
MCP App vs MCP Server: The Critical Distinction
An MCP server is a technical component; an MCP app is a product. The MCP server runs the protocol and exposes primitives (tools, resources, prompts). The MCP app is the marketed, distributed, supported, monetized package a customer installs β including the server, the auth experience, the marketplace listing, the documentation, and the support workflow.
| MCP server | MCP app | |
|---|---|---|
| Layer | Engineering | Product |
| What it is | Process implementing MCP (JSON-RPC 2.0) | User-installable product |
| Exposes | Tools, resources, prompts | A complete buyer experience |
| Who cares | Engineers, devops | Product, marketing, sales |
| Where it lives | Hosted endpoint or local binary | Marketplace listing in a host AI client |
| Used in | Architecture diagrams, technical docs | Roadmaps, investor decks, marketing |
One MCP app typically contains one MCP server, but an MCP app can package multiple servers when the product spans concerns (a company might ship an MCP app that installs both a "data" server and a "workflow" server under one product brand).
What about resources and prompts?
Most public discussion of MCP focuses on tools β the operations an agent can invoke. The other two primitives, resources and prompts, are underused in 2026 but worth understanding because they affect how you should think about your MCP app's surface.
Resources let an MCP server expose data the agent can read directly, without invoking a tool. Typical use cases: a knowledge base entry, a document, a database row. For some products β knowledge bases, documentation systems, content-rich CRMs β resources are a more natural fit than tools.
Prompts let an MCP server offer templated prompts users can trigger. A "summarize this ticket" prompt, a "draft response in our voice" prompt. Used in roughly 20% of production MCP apps as of mid-2026; tools are used in close to 100%.
Most product teams designing an MCP app should focus on tools first, resources second (where data exposure matters), and prompts third (where templated workflows matter). The terminology, though, should distinguish them β calling a resource a tool produces design discussions where engineering and product talk past each other.
A Working Vocabulary for Product Teams
After eighteen months of vocabulary churn, the stack we use with clients is the following.
MCP app β the umbrella term for the user-installable, distribution-aware product. Used in roadmaps, investor decks, internal naming, and any context where the thing is being discussed across host clients. MCP app is the word your CEO should be able to say in a board meeting and have everyone in the room understand the same thing.
Connector, app, or whatever the host client uses β the surface term in marketing and documentation, matched to where it appears. Inside Claude documentation: connector. Inside the ChatGPT app store: app. Inside Microsoft AppSource: whatever the AppSource template prescribes.
MCP server β the engineering artifact, used in technical documentation, partner contracts, and architecture diagrams. Not used in customer-facing copy.
Tool / Resource / Prompt β individual capabilities an MCP server exposes, used in product specs and developer docs. Never used in marketing.
The reasoning is that MCP app carries the right strategic weight β this is a product, not a script β without locking you to any single vendor's vocabulary. The host-specific term handles the language match on each client's surface. MCP server stays clean as the engineering term, which is what engineering wants.
Recommended Stack
MCP app for the umbrella term. Host-specific terms (connector inside Claude, app inside the ChatGPT store) on each client's surface. MCP server for the engineering artifact. Tool, resource, and prompt for individual capabilities. Pick a stack now; revisit when the market consolidates. The cost of waiting is paid in calendar weeks of vocabulary disagreement.
The objection worth taking seriously
The objection worth taking seriously is that MCP app overloads app, which already does too much work. True. But every alternative is worse: MCP server is the wrong layer; connector is one vendor's word; integration loses the autonomy signal; plugin is dated; skill is collided; extension and add-on undersell. App is overloaded. The alternatives are wrong. We accept the overload in exchange for the mental model.
Why Vocabulary Costs Calendar Weeks
The cost of mixed terminology is not abstract. Three concrete patterns we have seen on engagements show how the bill is presented.
The RFP that took six weeks to qualify. A buyer issues an RFP for AI integration capabilities. Three vendors respond β one describes their MCP server's tool surface, one describes their Custom GPT app, one describes a Zapier-style integration. The buyer's procurement team cannot compare the responses because the vendors are answering different questions under the same heading. Six weeks of clarification cycles before the actual evaluation can begin.
The investor deck that confused two stages. A series-B startup pitches an MCP server as their flagship product. Investors who track the category interpret this as a developer-infrastructure play (server = infrastructure). The actual product is a user-installable connector for Claude β a layer-three product that happens to ship with a server. Six weeks of follow-up conversations to re-position the narrative; one investor passes citing the confusion.
The partner contract that misallocated work. A company hires a development partner for MCP integration work. The partner scopes the engineering layer (server implementation, JSON-RPC handling, transport selection). The buyer expected the product layer (marketplace listing, distribution, support workflow). The first invoice exposes the gap; the contract is renegotiated mid-engagement at higher cost. A shared, scope-by-scope view of what an MCP server costs to build tends to surface that mismatch before the first invoice.
Common Failure Mode
In all three cases, the loss was not from any party acting in bad faith. It was from the absence of a shared vocabulary that could distinguish what was actually being discussed. The cheapest fix is a one-page vocabulary document circulated before the project starts. The expensive fix is renegotiating the contract or rebuilding the deck six weeks in.
The market will eventually settle. One term will win, the way app won over iPhone application. But if you are building an MCP-powered product in 2026, you cannot wait for that to happen. You need a working vocabulary now β one your engineers, your designers, your sales team, and your partners can all use without translation.
Pick a stack. Document it. Use it consistently. The rest of our MCP guide series uses MCP app as the umbrella term, MCP server for the engineering artifact, and host-client-specific terms (connector, Custom GPT app) where the host surface demands them.
Related Guides
- How to Embed Your App in AI Clients with MCP β The full strategic framework for product leaders shipping to leading AI clients
- MCP Client Comparison: Claude vs ChatGPT vs Cursor vs Copilot vs Gemini β The eight dimensions that matter when choosing where to ship
- MCP Embedding Types Explained: Read-Only vs Actions vs Agent-Resident β Choose the right level for your safety story
- MCP Build vs Buy β In-house engineering or development partner, with cost ranges and decision rubric
Frequently Asked Questions
Is an MCP server the same as an MCP app?
No. An MCP server is the engineering artifact β a process implementing the MCP spec via JSON-RPC 2.0. An MCP app is the user-installable product built on top of it, including auth experience, marketplace listing, documentation, and support. One MCP app typically contains one MCP server.
What are the three MCP primitives?
The MCP specification defines three primitive types an MCP server can expose: tools (operations the agent invokes), resources (data the agent reads), and prompts (templated user-facing prompts). Tools are used in nearly all production MCP apps; resources are used where data exposure is central; prompts are used least often.
What protocol does MCP use?
MCP uses JSON-RPC 2.0 as its wire protocol, transported over stdio (for local servers), SSE (Server-Sent Events over HTTP), or streamable HTTP (the consolidated remote transport). Capabilities are negotiated between client and server during session initialization.
Should I use the term connector or MCP app?
Use connector when you are inside Anthropic's vocabulary β Claude documentation, Claude marketing, conversations with Anthropic. Use MCP app as your cross-client umbrella term β roadmaps, investor decks, internal naming. Other host clients use other words; match the host client on the host client's surface.
Is an MCP server a plugin?
No. Plugin is inherited from the ChatGPT Plugins era of 2023 and implies an older, more constrained extension model. MCP-powered software is not a plugin; it is a protocol-based product surface with much broader capability β multiple primitives, capability negotiation, agent-driven invocation. Avoid plugin in current copy.
What is the difference between an MCP tool and an MCP server?
An MCP server is the package; a tool is one operation inside that package. A single MCP server typically exposes many tools β create_ticket, get_customer, list_invoices β alongside resources and prompts. The server is the install unit; the tool is the call unit.
Can I just call my MCP app an AI integration?
You can, but you lose information by doing so. Integration is a generic enterprise word that flattens the distinction between MCP and the previous generation of webhook-and-Zapier integrations. MCP is meaningfully different β agents reason about which tools to invoke based on natural-language context. Calling an MCP app an integration is operationally clear in procurement and strategically vague in positioning.
What's the difference between resources and tools in MCP?
A tool is an operation the agent decides to invoke (create_invoice, search_customers). A resource is a data item the server exposes for the agent to read (a specific document, a customer record). Tools have side effects or computed responses; resources are content. Tools are invoked; resources are referenced.
Originally published at launchdayadvisors.com. Launch Day Advisors is a buyer-side advisory firm: we help companies select AI, software, and design partners, and we are paid only by the buyer.
