The beginner series · 6 min

WTF Is an MCP?

How AI applications connect to external systems.

MCP is not another model, and it isn't magic. It's the Model Context Protocol — a standard way for an AI application to plug into outside tools and data, the way USB-C is one standard plug for very different devices. Instead of hand-building a custom connector for GitHub, then another for Slack, then another for your database, an app speaks MCP once and any MCP server can answer it. The server does the actual work; MCP just standardizes the socket between the AI and everything else.

Reading promise: No assumed AI knowledge. Jargon gets translated before it gets used.

The Problem MCP Is Trying to Solve

An LLM can generate language. That does not automatically mean it can read your GitHub repository, inspect your calendar, query your database, or create a ServiceNow incident. Those systems live elsewhere.

AI APPLICATION
   ├─ needs GitHub
   ├─ needs Calendar
   ├─ needs Database
   ├─ needs Files
   └─ needs Ticketing

Historically, every AI application could build its own bespoke connector for every external system. MCP—Model Context Protocol—standardizes a communication layer for these integrations. The official specification describes MCP as an open protocol for integrating LLM applications with external data sources and tools.[1]

A good analogy from the MCP documentation is USB-C: the connected devices can be completely different; the connector gives them a shared way to communicate.

Without a Standard

App A ── custom GitHub integration
      ├─ custom Slack integration
      └─ custom DB integration

App B ── another GitHub integration
      ├─ another Slack integration
      └─ another DB integration

With MCP

                 ┌─ GitHub MCP Server ── GitHub API
AI Application ─┼─ DB MCP Server ─────── Database
                 ├─ Files MCP Server ──── Files
                 └─ Calendar MCP Server ─ Calendar API

MCP Is Not the AI

An MCP server is not GPT, Claude, Gemini, or Llama. It does not become intelligent merely because it speaks MCP. It is better thought of as an adapter or capability provider.

LLM / AGENT = reasoning and language
MCP         = standardized communication
API/SYSTEM  = the external thing being accessed

Host, Client, Server

Current MCP architecture uses a client-server model. The host is the AI application. It creates MCP clients that communicate with MCP servers. Servers expose capabilities such as tools, resources, and prompts.[2]

YOU
 ↓
HOST (AI app)
 ├─ LLM
 ├─ MCP client ── MCP server A ── external system A
 └─ MCP client ── MCP server B ── external system B

The Three Server Primitives Beginners Should Know

PrimitiveBeginner translationExample
ToolsThings the AI application can invokesearch_tickets(), create_issue(), query_database()
ResourcesInformation the server can expose as contextfile contents, schemas, application data
PromptsReusable prompt/workflow templates/triage-alert, /summarize-incident

The 2026-07-28 specification defines tools as functions servers expose for model-driven interaction with external systems, and resources as server-provided context such as files, schemas, or application-specific data.[3][4]

A Calendar Example

You say: “Find a free hour tomorrow afternoon and schedule a meeting with Bob.” An agent might need a calendar capability. The MCP layer gives the host a standard way to discover and invoke what the calendar server offers.

USER: Schedule Bob tomorrow afternoon.
             │
             ▼
LLM: I need availability.
             │
             ▼
MCP tool: find_available_times
             │
             ▼
Calendar system returns 2:00 and 4:00
             │
             ▼
LLM chooses 2:00
             │
             ▼
MCP tool: create_event
             │
             ▼
Calendar system creates event

But Do APIs Already Do This?

Yes. MCP does not replace APIs. An MCP server often calls an API behind the scenes.

AI application
   ↓ MCP
MCP server
   ↓ service-specific API
GitHub / Salesforce / database / internal service

The value is standardization on the AI-facing side. An AI host can learn one protocol rather than inventing a completely different model-to-tool interface for every service.

MCP vs. Function Calling

Function/tool calling is about giving a model a structured way to request a function. MCP operates at a broader integration boundary: how hosts discover and interact with external capability providers. They can work together.

Function calling: "The model wants get_weather(city)."

MCP: "Here is a standard way for an AI host to discover
and interact with a server that exposes get_weather and other capabilities."

MCP vs. RAG

RAG describes a retrieval-and-generation pattern. MCP describes a protocol. An MCP resource or tool might supply information that is then placed into an LLM’s context and used in a RAG-like workflow—but neither requires the other.

MCP server → retrieve context → LLM
                     ↑
                 could be part
                   of RAG

MCP vs. an Agent

An agent decides what to do next. MCP can give it reach.

AGENT
  ├─ reason
  ├─ choose MCP tool
  ├─ observe result
  ├─ reason again
  └─ choose next action

Local vs. Remote MCP Servers

“Server” does not necessarily mean a rack in a data center. An MCP server can run locally as a process or remotely over a network. The current specification includes stdio for local process communication and Streamable HTTP for networked operation.[5]

LOCAL
AI app ── stdio ── local MCP process ── local files

REMOTE
AI app ── HTTP ── remote MCP server ── SaaS / API

A 2026 Implementation Note

MCP evolved quickly. The July 28, 2026 specification changed important protocol mechanics, including moving the core toward a stateless architecture. Older tutorials may describe lifecycle/session behavior from earlier revisions. Always check the revision a tutorial targets.[6]

A Cybersecurity MCP Example

This is where the idea becomes concrete. Imagine an investigation agent with MCP-accessible security systems:

Splunk MCP
 ├─ run_search
 └─ get_event

CrowdStrike MCP
 ├─ get_host
 ├─ get_detection
 └─ isolate_host

Okta MCP
 ├─ get_user
 └─ get_signin_events

ServiceNow MCP
 ├─ get_incident
 └─ create_incident

The agent investigates “suspicious login for alice@example.com.” It might query identity history, inspect endpoint telemetry, search SIEM events, then create an incident. MCP did not perform the investigation. It standardized the interfaces the agent used.

The Security Part Is Not Optional

Connecting AI to tools can turn a wrong sentence into a wrong action. read_file() and delete_file() are not equivalent risks. get_host() and isolate_host() are not equivalent risks. Production MCP deployments need identity, authorization, least privilege, approvals, audit logs, input validation, credential protection, and careful trust decisions.

  • Prefer read-only access when write access is not needed.
  • Require approval for destructive, externally visible, or expensive actions.
  • Do not assume third-party MCP servers are trustworthy simply because they implement a standard.
  • Keep the model’s effective permissions no broader than the workflow actually requires.
  • Log tool calls and preserve enough evidence to reconstruct what happened.

The Simplest Possible Definition

MCP is a standardized protocol that lets compatible AI applications discover and interact with external tools, data, and reusable prompt interfaces.
AI BRAIN      → LLM / agent
COMMON SOCKET  → MCP
EXTERNAL WORLD → APIs, files, databases, apps

Sources