MCP: The Standard That Connects Everything

Here is a problem you would hit within a month of building agents.

You wire your agent to your CRM. That takes a day. Then you want the same CRM available to a different assistant — a bespoke integration again. Then a colleague wants it in their workflow. Three integrations, three things to maintain, three things that break separately.

Multiply by every tool you use, and connecting AI to your systems becomes the whole job.

Model Context Protocol is the answer the industry converged on. A tool exposes an MCP server once, and any MCP-capable client can use it. Build the connection once, use it everywhere.

---

1. The idea, in one diagram

Before:

Assistant A  ──custom──>  CRM
Assistant B  ──custom──>  CRM
Workflow C   ──custom──>  CRM

Three integrations for one system.

With MCP:

CRM  ──exposes──>  MCP server
                        ↑
        ┌───────────────┼───────────────┐
   Assistant A     Assistant B     Workflow C

One server. Any client that speaks MCP can connect.

The analogy people use is USB: before it, every peripheral had its own connector. MCP is trying to be the standard connector between AI and everything else.

---

2. The two sides

You will meet MCP in two directions, and it is worth being clear which one you are doing.

	What it means	You use it when
MCP server	You expose something as a tool	You want your workflow, database or service callable by an AI
MCP client	You consume someone else's tools	You want your agent to use an existing service

The major automation platforms now support both. Your workflow can be a tool that an assistant calls, and it can call out to external MCP servers. That is what makes it a genuine ecosystem rather than another integration format.

---

3. What an MCP server actually offers

Three kinds of thing:

Tools — actions the AI can take. search_orders, create_ticket, send_invoice. This is the part you will use most.

Resources — data the AI can read. A document, a database table, a file.

Prompts — pre-written templates the server offers, so the AI does not have to guess how to use it well.

Most of the value, in practice, is in tools.

---

4. Using an existing MCP server

The common starting point: connecting your assistant to something that already speaks MCP.

Step 1 — Find out whether one exists. Many products now ship one. Check the product's docs for "MCP".

Step 2 — Get its connection details and credentials. A server usually needs authentication, exactly like an API.

Step 3 — Add it to your client. In an assistant that supports MCP, this is a configuration entry:

{
  "name": "company-crm",
  "url": "https://mcp.example.com/crm",
  "auth": { "type": "bearer", "token": "<YOUR TOKEN>" }
}

Step 4 — Check what it exposes. A well-behaved server tells the client what tools it has and what each one does. Read that list before using it — you are about to give an AI the ability to call every one.

Step 5 — Restrict it. Most clients let you enable specific tools rather than everything the server offers. Enable what you need and nothing else.

---

5. Exposing your own workflow as a tool

This is the move that changes how you build.

You have already built a lead-research workflow. Instead of it being something that runs on a trigger, you can expose it as a tool an assistant calls whenever it needs research done.

In n8n this is an MCP Server Trigger node; Make exposes scenarios through its MCP Server; Zapier exposes actions through Zapier MCP. The pattern is the same:

MCP Server Trigger
  name: research_company
  description: Given a company name or website, returns a short summary
    of what they do, who they sell to, and anything suggesting they are
    growing. Use when you need background on a company you do not know.
  input:  { company_name: string, website: string }
  output: { summary: string, signals: string[] }
  ↓
  [your existing workflow steps]

The description is the most important field you will write. It is how the calling AI decides whether and when to use your tool. Say what it does, what it returns, and when not to use it.

---

6. The security questions

MCP makes connection easy, which makes over-connection easy.

Least privilege. An MCP server exposing read and write is far more dangerous than one exposing read. Start read-only and add write access deliberately, per tool.

Who can call it? An MCP server reachable without authentication is an open door to whatever it wraps.

What happens on a bad call? Your tool will eventually be called with nonsense arguments. Validate inputs; do not assume the AI got them right.

Prompt injection is now higher stakes. An agent that reads a web page and has write-capable tools attached is the risk this course keeps returning to. Content it reads can instruct it. With MCP the tools are easier to attach, so the discipline matters more, not less.

Log every call. What was called, with what arguments, and what it returned. Without this you cannot investigate anything.

---

7. When MCP is worth it

Worth it:

• You want the same capability available to several assistants or workflows
• A tool you use already ships an MCP server
• You are building something a team will use
• You want to swap the AI underneath without rebuilding the connections

Not worth it yet:

• One workflow, one trigger, one user — a direct integration is simpler
• The tool has no MCP server and you would be building one from scratch for a single use
• You are still learning the basics of automation

The honest position: MCP is the right direction and it is where the ecosystem is going. It is not yet a reason to rebuild things that work. Design new things with it in mind; do not migrate working systems on principle.

---

⚠️ Common Mistakes

• Connecting a server and enabling every tool it offers. Enable what you need.
• Exposing write access on day one. Start read-only.
• A vague tool description. The calling AI uses it to decide. Vague descriptions produce misuse and wasted loops.
• No input validation. The AI will eventually pass nonsense. Validate.
• No authentication on your own server. It wraps your systems. Treat it accordingly.
• Treating it as a magic connector. It standardises the plumbing. It does not make an agent reliable, and it does not remove the need for a human in the loop.
• Rebuilding working integrations for the sake of the standard. New things, yes. Working things, later.

---

What's Next: You can connect an agent to anything. Now the older, more manual route — talking to APIs directly, which is still what you need when no MCP server exists.