What is MCP? Think of it as a common port for connecting AI applications to tools and external context

Suppose you are building an AI agent that must search GitHub, read company documents, query a database and access internal services.

Without a common integration layer, every connection may require its own custom adapter.

Model Context Protocol (MCP) is an open protocol designed to make those connections more standardized.

Think of MCP as a common connector

If every appliance used a completely different plug, every new device would require custom wiring.

MCP’s goal is similar to defining a shared connector format: compatible AI applications and servers can agree on how capabilities and context are exposed.

The standard does not make all tools identical. It standardizes parts of how they communicate.

MCP is not a model

A frequent misunderstanding is:

MCP ≠ LLM
MCP ≠ agent
MCP ≠ database

It is a protocol. HTTP is not a website; it is a set of rules used for communication. MCP occupies a similar conceptual layer for AI-tool integration.

Three roles: host, client and server

The MCP specification uses several architectural roles.

Host

The host is the AI application the user actually operates, such as an AI IDE, desktop assistant or chat application.

Client

A client inside the host manages a connection to an MCP server.

Server

An MCP server exposes capabilities and context.

Conceptually:

AI application / Host
  ↓
MCP Client
  ↓
MCP Server
  ↓
Files / GitHub / Database / Internal service

What can an MCP server expose?

Important server primitives include:

Tools

Tools are actions the model can invoke, such as:

search_issues
create_ticket
query_database

This connects directly to the tool-calling agent idea in Lesson 020.

Resources

Resources provide data or context: files, documentation, repository state or configuration information.

Prompts

Servers can also expose reusable prompt or workflow templates.

Why is this attractive to developers?

Without a shared protocol, two AI applications and two data services can require four separate integration paths.

With a common protocol, some of that repeated plumbing can be reduced. This is one reason MCP has become prominent in coding-agent and agent-tool ecosystems.

MCP does not replace APIs

Lesson 018 introduced APIs. They remain important.

An MCP server can itself be an adapter that receives an MCP tool call, invokes an existing API, and returns the result in a standardized way.

So MCP often sits above existing service APIs rather than replacing them.

A standard connector is not a safety guarantee

If a server exposes a destructive tool, the protocol does not make that tool safe automatically.

You still need authentication, authorization, input validation, tool allowlists, secret isolation, human approval and audit logs.

This is the same layered-security idea from Lesson 036.

Remote servers also raise data-governance questions: who runs the server, what data is sent, what permissions it receives and how long information may be retained.

One thing to remember

MCP standardizes how AI applications connect to tools, resources and external context. It can reduce custom integration work, but the protocol does not decide what permissions are safe—you still control the capabilities and data attached to the connector.