Summary
The Model Context Protocol (MCP) is an open standard by Anthropic that lets AI hosts wire up external tools, data sources, and prompt templates through a single transport layer. Frontend engineers care because MCP defines the UI surface: surfacing tool calls, rendering results, and getting user consent before an AI acts on their behalf.
Jump to the interview angleModel Context Protocol (MCP)
MCP is an open protocol (published by Anthropic, December 2024) that standardises how an AI application connects to external capabilities. The three roles are:
- Host — the AI application itself (e.g., Claude.ai, your chat product). It owns the conversation and decides which MCP servers to connect to.
- Client — a connector managed inside the host process that holds one persistent connection to one MCP server and mediates every message.
- Server — a lightweight process (local or remote) that exposes tools (callable functions), resources (read-only data, e.g. a file or DB row), and prompts (parameterised prompt templates).
The client-server channel uses JSON-RPC 2.0 over stdio or HTTP+SSE.
What the frontend needs to handle
- Render a tool-call card when the model invokes a tool, before the result arrives.
- Display the tool result inline once the server responds, keeping chat context intact.
- Gate destructive tools (file writes, API mutations) behind an explicit user approval step.
- Show which MCP server and tool name fired — users need provenance to trust AI actions.
- Handle tool errors gracefully; the model may retry or ask the user to intervene.
Tool call lifecycle in an MCP chat UI
- 1
Model emits a tool call
The LLM returns a structured tool-use block (name + JSON arguments) instead of plain text. The host intercepts it before displaying anything to the user.
- 2
Host routes to the right client
The host looks up which MCP client owns that tool name and forwards a
tools/callJSON-RPC request. If no server exposes the tool, the host surfaces an error. - 3
UI renders a pending tool card
Before the server responds, show a loading card with the tool name and arguments. This makes AI actions visible rather than silent — critical for trust.
- 4
MCP server executes and responds
The server runs the tool and returns a
CallToolResultwithcontent[](text or image parts). The client forwards it back to the host. - 5
UI renders the result and continues
Replace the pending card with the actual result. The result is appended to the conversation context and the model generates its next turn.
Human-in-the-loop: consent before action
Never auto-approve tool calls that write, delete, or send on behalf of the user. Present the tool name, server origin, and arguments in a confirmation dialog before the host forwards the call. Read-only tools (resources, search) can run silently; mutations need explicit approval. This is a UX contract, not just a policy — if users can't see or stop what the AI does, they won't trust the product.
Interview angle
Interviewers ask how you'd build a safe AI chat UI that calls external tools. Walk through MCP's host/client/server split, why tool calls must be surfaced in the UI, and how you gate destructive actions behind explicit user approval.
Soundbite: "The UI's job is to make tool calls legible and keep the user in control of what the model actually does."
Key terms
- MCP host
- The AI application that owns the conversation and manages one or more MCP client connections.
- MCP client
- A connector inside the host that holds one persistent JSON-RPC session to one MCP server.
- MCP server
- A process that exposes tools, resources, and prompts to any compliant MCP client.
- Tool (MCP)
- A named callable function on an MCP server; the model can invoke it with JSON arguments.
- Resource (MCP)
- Read-only data exposed by an MCP server (file, DB row, API response) the model can reference.