MCP concepts: hosts, clients, servers and primitives

Video lecture

MCP concepts: hosts, clients, servers and primitives

15 chapters · about 9 min · full transcript

Coming soon

Chapter 1 of 15

The Model Context Protocol (MCP)

One standard connector for AI apps
Hosts, clients, servers
Tools, resources, prompts

The narrated lecture is in production

Every chapter is scripted and ready. Browse the chapters and read the full transcript now — the video will appear here when it’s published.

Chapters

Transcript of the narration, chapter by chapter.

0:00 The Model Context Protocol (MCP)

Before USB, every printer, camera and keyboard came with its own cable and its own driver. AI integrations used to look like that drawer of adapters: one connector for your CRM in one assistant, another for the same CRM in the next assistant, and so on. The Model Context Protocol, MCP, is the universal port. In this lesson you'll learn its architecture, its building blocks, what changed in the latest specification, and why it matters to your business.

0:34 Why it matters

Why should a business person care about a protocol? Because protocols decide how much integration work you repeat. Before USB, every device needed its own port and driver. After USB, one standard port worked everywhere, and a whole ecosystem of devices appeared. MCP aims to do the same for AI: one way for any AI app to plug into your tools and data. Build a connection once, and reuse it across assistants, IDEs and agent platforms.

1:07 What MCP is

MCP is an open protocol that standardises how AI applications connect to tools, data and prompt templates. Build an MCP server for your system once, and any compatible application can use it. It was introduced by Anthropic in late 2024, adopted by AI apps, IDEs and platforms from many vendors, and in December 2025 it became a founding project of the Agentic AI Foundation under the Linux Foundation. The specification is versioned by date, and it keeps evolving, so always check the current version.

1:44 Architecture

There are three roles. The host is the AI application the user interacts with, such as a chat app, an IDE or an agent platform. It manages connections and, importantly, user consent. Inside the host, a client maintains the connection to one server. And a server is a program that exposes capabilities for one system, like a file store, database, ticketing tool or CRM. Messages are JSON-RPC. Local servers usually run as a subprocess over standard input and output. Remote servers use Streamable HTTP with OAuth-based authorisation.

2:22 Three primitives

Servers offer three main primitives. Tools are functions the model can call, like create invoice or search tickets, with names, descriptions and input schemas, exactly like the tool calling you've already learned. They're model-controlled, with the host handling consent. Resources are data exposed as context and identified by URIs, like a file or a record. They're typically application-controlled. And prompts are reusable templates or workflows, like summarise this ticket thread, usually picked by the user, often as a slash command.

2:57 Simple example: a shared-drive server

A simple example. You install an MCP server for your team's shared drive in your AI desktop app. The server offers a tool called search files, a resource for each document, and a prompt called summarise this folder. You ask: what did we agree with Al Noor Trading about delivery terms? The app lets the model call search files, the server returns two matching contracts, and the model answers with the clause and the file names. The same server works in your IDE and your agent platform.

3:35 What changed in 2026-07-28

The 2026-07-28 revision brought big changes, and they're worth knowing even if you never write protocol code. The core became stateless: no more initialise handshake or session ID, so each request carries its own version and capabilities, and remote servers can scale behind ordinary load balancers. When a tool needs input from the user mid-call, the server returns an input-required result and the client retries with the answers, called multi round-trip requests. Roots, sampling and logging were deprecated, and new capabilities like Tasks for long-running work and MCP Apps for server-rendered interfaces arrive as opt-in extensions.

4:17 Business value

Why does this matter for business? Reuse: one integration serves many AI apps. Ecosystem: ready-made servers exist for lots of common software, though you should vet them carefully, as the next lesson explains. Separation of concerns: the team that owns a system can own its server and decide exactly what's exposed. And portability: switching AI apps or models doesn't mean rebuilding integrations. Picture an operations team asking which enterprise customers have open high-priority tickets and renewals this quarter. Two servers, tickets and CRM, answer it together, and they keep working when the team changes assistant.

4:58 Business example (illustrative)

A deeper business example, illustrative. A mid-sized agency connected its ticketing tool and CRM through two MCP servers. Account managers now ask one question to see renewals with open high-priority tickets, instead of exporting two spreadsheets and matching them by hand, which used to take about an hour each Monday. When the agency later trialled a different AI assistant, both servers worked on day one, so the trial took a morning instead of a sprint.

5:31 Hands-on in the lesson

In the lesson's hands-on section you'll see how a developer can connect a remote MCP server directly inside a Claude API call using the MCP connector, and a simple mental model of what the host decides the model can see. MCP standardises the plumbing. It doesn't make a badly designed tool good, so everything from the tool design lesson still applies to MCP servers.

5:59 Common misconceptions

Common misconceptions to avoid. MCP is not a model, and it doesn't make any model smarter. It's not a security layer: an MCP server can be as dangerous as any software with access to your systems. It doesn't replace good tool design. And because the specification evolves, a tutorial from last year may use features that are now deprecated, like the older HTTP plus SSE transport or server-initiated sampling. Always check the current version.

6:31 How you'll know it's paying off

How will you know MCP is paying off for you? Count how many AI applications reuse each server you run: reuse is the whole point. Track the time to connect a new assistant to an existing system, which should drop from weeks to hours. And keep an eye on the reviewed and approved server list: a healthy MCP setup has fewer, well-owned servers, not dozens of unknown ones.

7:01 Watch me do it: MCP connector

Watch me do it. I open the connector example. First, I call client dot beta dot messages dot create, because the MCP connector is a beta feature, and I pass the beta name. Next, mcp servers: type url, a name, tickets, the server URL, and an authorisation token read from an environment variable, never pasted in. Then tools: an mcp toolset entry whose server name matches tickets exactly. If the names don't match, the request is rejected. Next, the user message asks which high-priority tickets are still open for enterprise customers. I run it and print the content blocks. I see the model's tool use against the tickets server, the tool result, and a text answer listing three ticket IDs. Finally, I remind myself of the host's role: the host decides what the model sees and which tools need approval, so I check those settings before giving anyone else access.

8:06 Recap

To recap: MCP is an open, dated, evolving standard for connecting AI applications to tools, data and prompts. Hosts manage consent, clients connect, servers expose capabilities as tools, resources and prompts. The latest revision is stateless, uses multi round-trip requests for user input, and grows through extensions. Your next step: list three internal systems you'd expose through MCP, and for each name two tools, one resource and one prompt. Next, we'll cover how to do all of this securely. For the full depth, see the Model Context Protocol flagship course.

8:45 Try this now (20 minutes)

Try this now. List three internal systems your team uses every day, like a CRM, a ticketing tool and a shared drive. For each, write two tools you'd want an assistant to have, one resource it should be able to read, and one prompt template people would pick. Mark each tool as read or write. Then check whether an official or trusted MCP server already exists for any of them before planning to build one.

The problem MCP solves

Before a common standard, every AI application needed custom integrations for every tool or data source: one connector for a CRM in one assistant, another for the same CRM in a different assistant, and so on. The Model Context Protocol (MCP) is an open protocol that standardises how AI applications connect to external tools, data and prompts. Build an MCP server for your system once, and any MCP-compatible application can use it.

A common analogy is a universal port: one standard connector instead of a drawer of adapters. MCP was introduced by Anthropic in late 2024, was adopted across AI applications, developer tools and platforms from many vendors, and in December 2025 became a founding project of the Agentic AI Foundation under the Linux Foundation. The specification is open, versioned by date (the current revision at the time of writing is dated 2026-07-28) and continues to evolve, so always check the current version at the official MCP site.

Architecture

MCP describes three roles:

Host: the AI application the user interacts with (a chat app, an IDE, an agent platform). The host manages connections and user consent.
Client: the connector inside the host that maintains a connection to one server.
Server: a program that exposes capabilities (tools, data, prompts) for a particular system, such as a file store, database, CRM or internal API.

Messages use JSON-RPC 2.0. Servers can run locally (the host launches them as a subprocess and talks over standard input/output, the stdio transport) or remotely (over Streamable HTTP, with OAuth-based authorisation for protected servers). The older HTTP+SSE transport is deprecated. The 2026-07-28 revision also made the protocol core stateless: the old initialise handshake and session ID header were removed, and each request carries its protocol version, client identity and capabilities, so remote servers can sit behind ordinary load balancers. Details like these change between versions, which is one reason to build on maintained SDKs rather than hand-rolling the protocol.

Server primitives

MCP servers can offer three main kinds of capability:

Tools: functions the model can call to take actions or fetch information (for example create_invoice, search_tickets). These work like the tool calling you learned in module 3, with names, descriptions and JSON Schema inputs. Tools are generally model-controlled: the model decides when to call them, with the host responsible for consent.
Resources: data the server makes available as context, identified by URIs (for example a file, a database record or a document). Resources are typically application-controlled: the host decides how to present or include them.
Prompts: reusable, parameterised prompt templates or workflows the server offers (for example "summarise this ticket thread"), typically user-controlled, often surfaced as commands the user picks.

The specification also defines ways for a server to involve the user or the client. Elicitation lets a server ask the user for missing information (a confirmation, a date, a choice) during an operation; in the 2026-07-28 revision this happens through multi round-trip requests, where the server returns an "input required" result and the client retries the call with the answers attached, instead of the server opening a request back to the client. Earlier revisions also defined sampling (servers requesting model completions through the client), roots (clients telling servers which locations they may use) and logging; the 2026-07-28 revision deprecates these, with at least twelve months before any removal. New capabilities now arrive as opt-in extensions, for example Tasks for long-running work and MCP Apps for server-rendered user interfaces. This is exactly the kind of detail that changes, so check the current specification before depending on a particular feature.

What an MCP tool looks like

Conceptually, a server advertises tools with the same ingredients you already know:

{
  "name": "search_tickets",
  "description": "Search support tickets by text, status and date range. Returns up to 20 tickets with id, subject, status and last_updated.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": {"type": "string"},
      "status": {"type": "string", "enum": ["open", "pending", "closed"]}
    },
    "required": ["query"]
  }
}

The host lists available tools from connected servers, provides them to the model, and routes the model's tool calls to the right server.

Why it matters for business

Reuse: one integration serves many AI applications.
Ecosystem: many ready-made servers exist for common software. Evaluate them carefully (next lesson).
Separation of concerns: the team that owns a system can own its MCP server, controlling exactly what is exposed.
Portability: switching AI applications or models does not mean rebuilding integrations.

Worked example

An operations team wants their AI assistant to answer "Which enterprise customers have open high-priority tickets and renewals this quarter?" They connect two MCP servers: one for the ticketing system (tool: search_tickets) and one for the CRM (tools: find_accounts, resource: account records). The model calls both, joins the results in its reasoning, and cites ticket IDs and account names. When the team later adopts a different AI application that supports MCP, both servers work without changes.

Hands-on: connect a remote MCP server to a model call

You can see MCP working without writing a server: many hosts (desktop chat apps, IDEs, agent platforms and no-code tools such as n8n) let you add a server by URL or command. Developers can also connect remote MCP servers directly in an API call. With Anthropic's Messages API, the MCP connector (a beta feature at the time of writing) needs two halves: the server in mcp_servers and a matching mcp_toolset entry in tools.

import os
import anthropic

client = anthropic.Anthropic()
resp = client.beta.messages.create(
    model=os.environ.get("ANTHROPIC_MODEL", "claude-opus-5"),
    max_tokens=4000,
    betas=["mcp-client-2025-11-20"],                 # check the docs for the current beta name
    mcp_servers=[{"type": "url", "name": "tickets",
                  "url": "https://mcp.example.com/mcp",   # your remote MCP server
                  "authorization_token": os.environ["TICKETS_MCP_TOKEN"]}],
    tools=[{"type": "mcp_toolset", "mcp_server_name": "tickets"}],
    messages=[{"role": "user", "content": "Which high-priority tickets are still open for enterprise customers?"}],
)
for block in resp.content:
    print(block.type, getattr(block, "text", ""))

For local servers, prompts, resources or finer control, use an MCP client library in your own application (the official Python SDK's Client, for example) and pass the tools to the model yourself. You will build a small server in the lesson "Building an MCP server".

A mental model to keep

Host (chat app / IDE / agent)  --manages consent, shows tools-->  User
   |-- MCP client --> Server A (tickets): tools, resources, prompts
   |-- MCP client --> Server B (CRM):     tools, resources, prompts
Model sees: tool definitions + resource content chosen by the host

The host decides what the model sees and what needs the user's approval. That is why the choice of host, and its settings, matters as much as the servers you connect. The flagship Model Context Protocol (MCP) course covers transports, authorisation, extensions and production deployment in depth.

Going further

Official SDKs exist for several programming languages, along with tools for testing and inspecting servers. When building a server, apply everything from the tool design lesson: task-level tools, clear descriptions, concise results and informative errors. MCP standardises the plumbing; it does not make a badly designed tool good.

MCP is an open, versioned protocol standardising how AI applications connect to tools, data and prompts.
Hosts manage user-facing apps and consent, clients connect to servers, servers expose capabilities; messages use JSON-RPC 2.0.
Server primitives: tools (model-controlled), resources (application-controlled data) and prompts (user-selected templates).
The specification evolves; check the current version and use maintained SDKs.

List three internal systems you would expose via MCP. For each, name two tools, one resource and one prompt template you would offer.

Enrol for free to save your progress

Reading is always free. Enrol to keep your place, take the final assessment and earn a verifiable certificate.

MCP concepts: hosts, clients, servers and primitives