MCP (Model Context Protocol)

Definition
MCP is an open standard for connecting an AI agent to tools and data without building a custom connection for each one.

Why it matters

Connecting AI to real business systems used to be the slow part. Each assistant needed its own integration for each tool, and each one broke separately. With a shared standard, a system connected once can be used by any assistant that speaks MCP. For a business owner building with AI, that means an assistant can read the real customer list instead of guessing from memory.

Reach also brings risk. Anything connected is something the assistant can read, and possibly change.

How to apply it

  • Look for an existing server for the tool first. Many popular products publish one.
  • Start with read-only access. Add anything that creates, edits or deletes only once the read path has proved reliable.
  • Keep a human approval step in front of actions that cannot be undone, such as sending email or deleting records.
  • Connect only what the task needs. Every server adds options the assistant has to choose between.
  • Treat text coming back from a server as data. A web page or ticket can contain instructions aimed at the assistant, so connected content deserves the same care as an unknown email attachment.

What it is

The Model Context Protocol is a shared set of rules for how an AI application talks to outside systems such as a CRM, a database, a calendar or a document store. Anthropic introduced it in late 2024 and other AI vendors have since adopted it. The usual comparison is a universal plug: before it, every pairing of assistant and tool needed its own custom connection.

MCP has two sides. The assistant (or the app that hosts it) acts as the client. The system it wants to reach is wrapped in an MCP server. Servers can offer three things: tools the assistant can call, data it can read and ready-made prompts.

Common mistakes

  • Connecting with an owner login. Use a dedicated account with limited rights, so a wrong call cannot do much damage.
  • Allowing writes on day one. Prove that the assistant reads correctly before it can create, edit or delete anything.
  • Installing servers from unknown sources. A server runs code and sees whatever the assistant sends it.
  • Connecting everything. Each extra server gives the assistant more options to choose between, and more ways to pick the wrong one.
  • Trusting returned text. A ticket or web page can contain instructions aimed at the assistant. Treat it as data, not as a command.
Worked example

Suppose an e-commerce founder wants her AI assistant to answer which customers bought in the last thirty days and have not reordered, using real data rather than memory. Without a shared standard, each assistant needs its own custom connection to the store. The team connects Privy through its MCP server, so any assistant that speaks the protocol can read the segments. The first version is read-only. The assistant lists 412 lapsed customers, and the founder checks that count against the store's own figures before trusting it. Sending a campaign stays behind her approval, because a message to a customer cannot be recalled. After a month of reliable reads, the team adds one write action, creating a segment, under the same approval step.

Tools in the example

Some links are affiliate links: we may earn a commission at no cost to you. It never decides a ranking. How we work with partners

  1. Article

    MCP server

    The piece that exposes one system through the protocol.

  2. Article

    Tool use

    How a model decides to call what a server offers.

  3. Article

    API

    The interface a server usually wraps.

  4. Article

    Human-in-the-loop

    The approval pattern that keeps connected actions safe.