Home / AI Architecture & System Design / Agents & LLM Applications

Agents & LLM ApplicationsJuniorQuestion 7 of 9

What is MCP?

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

0–5 min Functional requirements

Start with a two-sentence definition, then make it a design problem: building and rolling out MCP integrations safely inside a company.

You MCP, the Model Context Protocol, is an open standard for connecting AI applications to tools and data. An application (the host) runs an MCP client for each server, and servers expose tools, resources and prompts over JSON-RPC, so an integration is written once and works in any MCP-capable host. Shall I design how we'd use it?

Interviewer Yes. We want our internal ticketing system and our metrics database available to employees' AI assistants: the IDE assistant, the chat app, and an internal agent platform.

You Who should be able to do what? Read only, or create and update tickets too?

Interviewer Everyone can read tickets for their projects; creating and updating should be possible but controlled. Metrics are read-only.

You Will employees also connect third-party MCP servers?

Interviewer They want to. Security is nervous about that.

5–10 min Non-functional requirements and estimates

Back-of-envelope estimates:

• Load: 10,000 employees × ~20 tool calls/day ≈ 200,000 calls/day, ~10/s at peak. Modest; latency and correctness matter more than throughput.
• Tool definitions cost tokens: if each tool's description and schema is ~150 tokens and a host loads 5 servers × 8 tools, that's ~6,000 tokens in every request before the user says anything. Keep tool sets small and descriptions tight, or load tools on demand.
• Results: a "list tickets" call returning 200 full tickets could be 60,000 tokens; returning 20 summaries with IDs and a next_cursor is ~1,500.

10–18 min High-level design

You Each host runs one MCP client per server. Our servers are remote (HTTP transport) with OAuth so they act as the employee, and they enforce permissions themselves. A registry controls which servers managed hosts may connect to.

Components:

• Hosts: the IDE assistant, chat app and agent platform. Each manages the model, user approvals and the list of connected servers.
• MCP clients: one per server connection, inside each host.
• Ticketing server: tools like search_tickets, get_ticket, create_ticket, add_comment, update_status; resources for ticket templates; prompts like "triage this ticket".
• Metrics server: read-only tools like query_metric(service, metric, window) and list_dashboards.
• Authorization server (OAuth): issues short-lived, scoped tokens per user; servers call backends with the user's identity.
• Server registry: approved servers, versions, owners and risk notes; managed hosts only connect to registered servers.
• Audit log: user, host, server, tool, arguments (redacted), result status.

The protocol lifecycle:

A well-designed tool definition:

{
  "name": "search_tickets",
  "description": "Search tickets in projects the user can access. Use for finding existing tickets before creating a new one. Returns up to 20 summaries; use get_ticket for full details.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query":   { "type": "string", "description": "Keywords or a ticket key like OPS-123" },
      "project": { "type": "string", "description": "Project key, e.g. OPS" },
      "status":  { "type": "string", "enum": ["open", "in_progress", "closed"] },
      "cursor":  { "type": "string", "description": "Pagination cursor from a previous call" }
    },
    "required": ["query"]
  }
}

18–32 min Deep dive

You I'd go deeper on security, designing tools the model uses well, and how MCP relates to function calling.

Interviewer Security first. What worries you?

Deep dive 1 · Security

• Act as the user: OAuth with per-user, short-lived tokens and narrow scopes (tickets:read, tickets:write). The server checks project permissions on every call; the host and model are never trusted to enforce them.
• Approvals for writes: hosts auto-approve read tools and ask before write tools, showing the exact action ("Create ticket in OPS: 'Checkout latency spike', priority P2").
• Untrusted content: ticket descriptions and comments are written by people, and may contain injected instructions. Tool results are data; write actions still require approval.
• Tool poisoning: a malicious third-party server can put instructions in its tool descriptions. Review descriptions as part of registry approval, pin server versions, and alert on changes.
• Combinations: a server that reads private data plus a server that fetches the web plus one that can post externally recreates the lethal trifecta. The registry should flag risky combinations, and policies can block them in the same session.
• Local servers (stdio) run with the user's local permissions; managed laptops should restrict which ones can be installed.

Interviewer How do you make the tools work well for the model?

Deep dive 2 · Designing good tools

• Task-shaped, not API-shaped: search_tickets and create_ticket rather than mirroring 40 REST endpoints. Fewer tools mean fewer wrong choices and fewer tokens.
• Descriptions say when to use the tool, what it returns and its limits; they're effectively prompts.
• Compact results with handles: summaries plus IDs, and pagination cursors.
• Helpful errors: "Project 'OPS2' not found. Did you mean 'OPS'?" lets the model recover.
• Idempotent writes: create_ticket accepts a client-generated key to avoid duplicates on retry.
• Test with an evaluation set: tasks like "find the open P1 for checkout and add a comment" measure tool-choice accuracy and argument correctness.

Deep dive 3 · MCP and function calling

They work together: the host converts MCP tool definitions into the model API's tool format, and routes the model's tool calls to the right server.

32–37 min Trade-offs

Build first: the read-only metrics server and read tools for tickets with OAuth and audit logging; then write tools with approvals; then the registry for third-party servers.

37–40 min Wrap-up and likely follow-ups

Close with: "MCP standardizes how hosts discover and call tools and data, so we build ticketing and metrics servers once and use them in every assistant. They run remotely with per-user OAuth, enforce permissions server-side, expose a few task-shaped tools with compact results, and require approval for writes. A registry governs third-party servers, including reviewing tool descriptions for poisoning and flagging risky combinations."

Likely follow-ups:

• How do you version a server without breaking hosts? Additive changes (new optional parameters, new tools) are safe; for breaking changes, add new tools and deprecate old ones over time.
• How do you keep tool definitions from bloating every prompt? Connect only the servers a task needs, or let the host load tools on demand.
• Would you expose resources as well as tools? Yes, for things the application (not the model) should attach as context, like ticket templates or a runbook.

What interviewers listen for

• A correct picture of host, client and server, and the primitives.
• Acting as the user, server-side authorization and approvals for writes.
• Awareness of tool poisoning and risky server combinations.
• Tool design for model usability and context efficiency.

Red flags

• A shared admin credential behind the server.
• Mirroring every API endpoint as a tool.
• Treating third-party servers as trusted.