Guide
MCP servers explained for non-developers
No protocol diagrams, no code. Just the handful of ideas you need to evaluate, buy, or approve an MCP connector with confidence.
An MCP server is like a trained assistant sitting between Claude and one piece of your software. It knows exactly which levers that software has, exposes only the ones you allowed as named tools, and operates them on Claude's behalf using your own login. MCP is simply the shared standard that lets Claude work with any such assistant.
Key takeaways
- MCP is a shared standard, like a common plug shape, so Claude can work with any tool built to it.
- An MCP server (or connector) is the go-between for one piece of software; tools are its individual levers.
- Read tools and write tools are deliberately separate, so looking things up never risks changing them.
- OAuth means you log in with your own account, and the server can only do what your login can.
What is MCP in plain English?
MCP, the Model Context Protocol, is a shared standard for how an AI assistant talks to other software. Think of it like the standard wall socket: because everyone builds to the same plug shape, any appliance works in any building. Because software exposes itself through MCP, Claude can work with any of it the same way.
Before standards like this, every AI-to-software connection was a custom, one-off wiring job. MCP replaces that with one agreed format: here is how you describe what a piece of software can do, and here is how the AI asks for one of those things to be done.
You never see MCP directly, the same way you never think about the socket standard when you plug in a lamp. What you see is the result: Claude able to look things up and take actions in your real systems from inside a normal conversation.
If you want the more technical version of how MCP relates to APIs, the MCP vs API explainer covers that layer. This post stays at the business level.
What is an MCP server, really?
An MCP server is the go-between for one specific piece of software. Picture a trained assistant sitting between Claude and your CRM: the assistant knows exactly which levers the CRM has, has been told which ones it is allowed to pull, and pulls them only when Claude asks on your behalf.
The words server and connector both describe this same go-between. Server is the technical name for the program; connector is what it looks like from inside Claude, an item you add to your workspace so a new set of abilities appears.
Two things about the assistant analogy carry real weight. First, the assistant is specific: one MCP server knows one system deeply rather than everything shallowly, and a team typically attaches several, one per tool. Second, the assistant is trained on your levers, not generic ones. A custom connector is built around your actual fields, pipelines, and rules, which is what makes its answers land in your vocabulary instead of a generic one.
Where that go-between physically runs, on a laptop or hosted for the whole team, matters for sharing and upkeep, and the remote vs local MCP servers post covers that question on its own.
What are MCP tools?
Tools are the individual levers the assistant can pull, each with a name and a plain-language description. A CRM connector might offer `search_contacts`, `get_deal`, and `update_deal_stage`. When you ask Claude something, it reads those descriptions, picks the right lever, fills in the details, and asks the server to pull it.
The important shift here is from open-ended access to a fixed menu. The connector does not hand Claude the keys to the software; it hands Claude a list of specific, named actions and nothing else. If there is no delete_contact tool on the menu, deleting contacts is simply not something Claude can do through that connector, no matter how a request is phrased.
That menu is also where a custom build earns its keep. The tools can match how your business actually talks: log_site_visit for a field-services team, flag_claim_for_review for an insurance workflow, rather than generic verbs bolted onto generic objects.
Why are read and write tools separated?
Because looking and touching carry completely different risk. Read tools like `search_tickets` only fetch information, so Claude can use them freely as a conversation unfolds. Write tools like `update_record` change your system, so they are built as separate, clearly labeled actions, and the riskiest ones sit behind a confirmation you approve.
The separation gives you a dial instead of a switch. A team can start with a read-only connector, get comfortable, and add writes later. Within writes, there is another gradient: routine updates can flow inside the conversation, while destructive or outward-facing actions, deleting records or sending messages, stop and wait for a human yes.
A question worth asking any connector builder
Ask which tools are read, which are write, and which writes require confirmation. A good builder answers with a specific list per tool. A vague answer about the AI being careful is a red flag.
This is the same human-in-the-loop pattern that governs all responsible AI write access, and it lives in the connector's design, not in hoping the model behaves.
What does OAuth do, in plain terms?
OAuth is the sign in with your account step you already know from other apps. When you connect a connector, you log into the underlying software as yourself and approve exactly what the connector may do. From then on, everything the connector does runs under your identity and your permissions.
Two consequences of that are worth spelling out.
- The connector never learns your password. OAuth hands it a limited, revocable token instead, and you can cut it off from the software's settings at any time.
- The connector can never exceed you. If your account cannot see executive dashboards or edit other regions' records, neither can Claude acting through your connection.
For a team, this means ten people using the same connector get ten different, correctly scoped views, without anyone managing a shared password or an all-powerful service account.
What should a non-developer actually remember from all this?
Four sentences cover it. MCP is the shared standard that lets Claude work with business software. An MCP server, or connector, is a trained go-between for one specific system. Tools are its fixed menu of named actions, with reads and writes kept separate. OAuth ties everything to your own login and permissions.
With those four ideas you can hold your own in any conversation about connecting Claude to your systems: what is being proposed, what it will and will not be able to do, and where the safety boundaries live.
And you can ask the questions that matter: which tools will exist, which are writes, what gets a confirmation gate, and who keeps the connector working as the software underneath it changes.