Home / Question bank / Coding with AI APIs

Coding with AI APIsJuniorQuestion 8 of 11

What is MCP?

30-second answer

The Model Context Protocol is an open standard for connecting AI applications to tools and data through a client–server interface. A server exposes tools, resources or prompts; any MCP-capable client can use them. It reduces one-off integrations. Security considerations include trusting servers, scoping credentials, and treating server outputs as untrusted content.

Try answering out loud before reading on. The walkthrough below is paced for a 40-minute interview round.

Architecture diagram

Sketch this on the whiteboard as you talk through the answer. See all AI architecture diagrams →

Scroll sideways to see the whole diagram.

MCP architectureComponents: LLM (emits tool calls); Host runtime (approvals · routing); User (approves writes); MCP client; MCP client; MCP client; GitHub server (local · stdio); Database server (local · stdio); Ticketing server (remote · HTTP + OAuth); GitHub API; Postgres; Ticketing SaaS. Flow: LLM to Host runtime; User to Host runtime (approve); Host runtime to MCP client; Host runtime to MCP client; Host runtime to MCP client; MCP client to GitHub server (JSON-RPC); MCP client to Database server (JSON-RPC); MCP client to Ticketing server (JSON-RPC); GitHub server to GitHub API; Database server to Postgres; Ticketing server to Ticketing SaaS.HOST APPLICATIONLLMemits tool callsHost runtimeapprovals · routingUserapproves writesMCP clientMCP clientMCP clientGitHub serverlocal · stdioDatabase serverlocal · stdioTicketing serverremote · HTTP + OAuthGitHub APIPostgresTicketing SaaSapproveJSON-RPCJSON-RPCJSON-RPC
MCP architecture. The host runs one MCP client per server. Local servers speak JSON-RPC over stdio; remote servers use HTTP with OAuth. The host decides which tool calls need user approval.

0–5 min Clarify and frame

Ask whether they want the concept, the protocol details, or how you'd build or secure an MCP server. Framing: "MCP is an open standard for connecting AI applications to tools and data, so an integration is built once and used by many clients. I'll cover the architecture, primitives, lifecycle, how it relates to function calling, and security."

5–15 min Core explanation

The problem: M AI applications × N services means M×N custom integrations. MCP turns that into M clients + N servers speaking one protocol.

Roles:

  • Host: the AI application (a chat app, an IDE, an agent runtime). It manages the model, the user and permissions.
  • Client: the protocol connection inside the host; one per server.
  • Server: a program exposing a system's capabilities (a database, GitHub, a file system, an internal API).

Primitives a server can offer:

Primitive Controlled by Purpose
Tools Model (with host approval) Functions to call, with JSON Schema inputs
Resources Application Readable data (files, records) to provide as context
Prompts User Reusable templates or workflows

Messages use JSON-RPC 2.0. Transports include stdio for local servers and HTTP-based streaming transports for remote servers, with OAuth-based authorization for remote services.

15–25 min Deep dive: lifecycle

  1. Initialize: client and server exchange protocol versions and capabilities.
  2. Discover: the host lists tools/resources/prompts.
  3. Expose to the model: the host converts tool definitions into the model API's tool format.
  4. Invoke: the model emits a tool call; the host (possibly after user approval) sends tools/call to the server.
  5. Return: the server responds with content; the host passes it to the model as a tool result.
  6. Notifications: servers can signal that their tool list or resources changed.

Relation to function calling: function calling is the model-API mechanism for emitting structured calls; MCP standardizes how those tools are discovered, described and connected across applications. They're complementary.

25–32 min Security considerations

  • Trust: a server can do anything its credentials allow; review it like any dependency and pin versions.
  • Credentials: prefer per-user OAuth with least-privilege scopes over shared service keys.
  • Tool descriptions and results are untrusted text: they can carry prompt injection ("tool poisoning").
  • Combinations: connecting a server with private data, one that fetches web content, and one that can send messages recreates the lethal trifecta.
  • Approvals: require user confirmation for write or destructive tools; auto-approve only safe reads.
  • Server-side enforcement: the server must check the calling user's permissions; never rely on the model to stay in bounds.

32–37 min Production example

A company exposed its internal ticketing system as one MCP server so the same integration worked in their IDE assistant and their chat assistant. Read tools were auto-approved; create_ticket and update_status required confirmation. The server authenticated users via OAuth and enforced each user's project permissions. Building it once replaced two divergent custom integrations.

37–40 min Likely follow-ups

  • How would you design a good MCP server? Few, task-oriented tools with clear descriptions; filtered, compact results; pagination; helpful error messages.
  • How do you test one? Unit tests on handlers, protocol conformance tests, and agent evals using the server.

What interviewers listen for

  • Host/client/server roles and the three primitives.
  • How MCP relates to function calling.
  • Concrete security risks and controls.

Red flags

  • Treating any third-party MCP server as trusted.