MCP, Connectors, and Plugins: A Glossary for Builders¶

If you've tried to connect an AI assistant to your own product or data, you've probably run into a wall of overlapping terms: MCP, connector, plugin, GPT, Action, desktop extension. They get used loosely, sometimes interchangeably, even though they mean different things and solve different problems. This is the glossary we wished existed before we built Opionate's own AI integrations - short definitions, and a sense of when each one actually applies.

MCP (Model Context Protocol)¶

MCP is a protocol, not a product. It defines a standard way for an AI assistant to discover and call tools exposed by an external system - read a file, search a database, create a record - regardless of which AI assistant or which system is on the other end. Think of it as the plumbing standard, not the faucet itself.

Two roles matter here:

• MCP server - the thing you build and host. It exposes a set of tools (functions an AI can call) over the protocol.
• MCP client / host - the AI application that connects to a server and calls its tools. Claude.ai, Claude Desktop, Claude Code, and (more recently) ChatGPT can all act as MCP clients.

Custom Connectors (Claude)¶

A custom connector is how a remote MCP server gets added to Claude.ai or Claude Desktop. You (or your user) paste in the server's URL, go through an authorization step if the server requires sign-in, and Claude can then call that server's tools mid-conversation. This is the right shape when your MCP server lives on your own infrastructure and multiple users need to connect to it independently, each with their own scoped access.

Desktop Extensions (.dxt)¶

A desktop extension is a locally-packaged MCP server bundled for Claude Desktop specifically - installed as a file on the user's machine rather than connected to over the network. This fits a different case than a custom connector: a tool that needs to run on the user's own computer (touching local files, a local database, a local dev environment) rather than calling out to a hosted service.

Claude Code's MCP Config¶

Claude Code (the CLI/IDE agent) can also connect to MCP servers, configured per-project or per-user rather than through a settings UI. Same protocol, same server code as a custom connector or desktop extension - just a different client with its own configuration path.

GPTs and Actions (ChatGPT, pre-MCP)¶

Before ChatGPT adopted MCP, its extensibility model was GPTs (custom configurations of ChatGPT with instructions and knowledge) combined with Actions - API calls described via an OpenAPI schema that the GPT can invoke. This is a different mechanism than MCP entirely: no shared protocol, no tool-discovery handshake, just a schema you describe once per GPT. The original ChatGPT Plugins system that predated GPTs/Actions has been deprecated for some time.

Connectors and the Apps SDK (ChatGPT, current)¶

ChatGPT has since moved toward its own connector model, built on the same MCP standard via OpenAI's Apps SDK - meaning a well-built MCP server can, in principle, serve both Claude and ChatGPT without being rebuilt twice. Naming and rollout details on the ChatGPT side move quickly; treat this section as directional and check OpenAI's current documentation before committing to specifics.

So Which One Do You Actually Build?¶

• Building an integration multiple users will connect to remotely, each with their own account/permissions? Build an MCP server, expose it as a custom connector (Claude) and/or connector (ChatGPT). This is what Opionate's own AI integrations do - see Connecting Opionate to Claude via MCP.
• Building something that only needs to run on one user's own machine, touching local resources? A desktop extension is the closer fit.
• Already invested in ChatGPT's GPT/Action model and don't need Claude support? Actions still work and don't require adopting MCP - but you won't get Claude compatibility for free.

FAQ¶

Is MCP an Anthropic-only standard?
No - it's an open protocol. Anthropic created it, but it's designed to be implemented by any AI assistant or any server, which is why ChatGPT has moved toward supporting it too.

Do I need to pick one integration method and stick with it?
Not necessarily. An MCP server and a ChatGPT Action can coexist if you're supporting both ecosystems during a transition - they just aren't the same code path.

Where does OAuth fit into all this?
A custom connector that needs to act on a specific user's own data (not just public information) typically requires an authorization step - usually OAuth - so the server knows which user is calling and can scope access accordingly. See Connecting Opionate to Claude via MCP for what that looks like in practice.

Ready to see this in practice? Start with Connecting Opionate to Claude via MCP.