Agents & Tools Interview Prep

Course Content

Agents & Tools Interview Prep

6 sections · 40 lessons

How does MCP’s client-server architecture work?

Host, clients, transports, serversHost — model, UI, consent, policyOne client per server, isolatedstdio locally, Streamable HTTP remotelyServer — tools, resources, prompts
Servers never see the model or each other; everything crosses the host, which is where approval and audit belong.

What you need to know

The three roles

RoleWhat it isResponsibilities
HostThe AI app: a desktop assistant, an IDE, your agent serviceRuns the model, shows the UI, asks for consent, enforces policy
ClientA connector inside the host, one per serverSends requests, receives results and notifications
ServerA program exposing one systemLists and runs tools, serves resources and prompts

One client per server keeps servers isolated: the GitHub server cannot see the Postgres server's traffic, and neither sees the full conversation — only the requests the host sends.

Transports

stdio

  • Host starts the server as a local subprocess
  • JSON-RPC over stdin and stdout
  • No network port, no HTTP auth
  • Credentials come from the environment

Streamable HTTP

  • Server runs remotely as a web service
  • Client sends JSON-RPC in HTTP POSTs to one endpoint
  • Reply is JSON or a streamed (SSE) response
  • Authorisation based on OAuth 2.1

The older "HTTP+SSE" transport (two endpoints) is deprecated; new remote servers use Streamable HTTP.

How a conversation with a server looks

JSON
{"jsonrpc": "2.0", "id": 7, "method": "tools/call", "params": {"name": "search_issues", "arguments": {"query": "login timeout"}}}
JSON
{"jsonrpc": "2.0", "id": 7, "result": {"resultType": "complete", "content": [{"type": "text", "text": "3 issues found: #4790, #4655, #4401"}], "isError": false}}

Stateless since the 2026-07-28 spec

Earlier spec versions (up to 2025-11-25) started every connection with an initialize handshake to agree the protocol version and capabilities, and Streamable HTTP used a session id header. The 2026-07-28 revision removed both:

  • Every request carries its protocol version and client capabilities in _meta.
  • Servers implement server/discover, which clients may call first to learn supported versions and capabilities.
  • Servers that need state across calls return explicit handles (for example a basket_id) as ordinary tool arguments.

Many deployed servers still speak the older version, and the official SDKs handle both. In an interview, knowing the handshake existed and that the current spec dropped it shows you are up to date.

A real-life example

A developer's IDE assistant (the host) connects to two servers:

  • A filesystem server over stdio. The IDE starts it as a subprocess with access only to the project folder. No port is opened, so nothing else on the network can reach it.
  • The company's Jira server over Streamable HTTP at https://mcp.internal.example.com/jira. The first time, the IDE sends the developer through the company's OAuth login; the server then sees requests carrying that developer's token and returns only the projects they can access.

When the developer asks, "Which Jira tickets mention the file I'm editing?", the model calls a filesystem tool and a Jira tool. The host routes each call to the right client, gets results back, and passes them to the model. The Jira server never sees file contents, and the filesystem server never sees Jira data — the host decides what flows where.

Follow-up questions to expect

  • "Why one client per server?" — Isolation and simpler failure handling: one crashed or malicious server cannot read another's traffic, and each connection has its own auth.
  • "When would you pick stdio over HTTP?" — For local tools on the user's machine (files, local git), where you want no network exposure and no shared deployment.
  • "Where does authorisation happen?" — For HTTP servers, the server validates an OAuth access token on each request and enforces what that user may do; the host handles the login flow.