MCP Deep Dive

What MCP is (the 60-second pitch)

MCP is an open protocol — published by Anthropic in late 2024 — that standardizes how AI applications connect to external tools, data sources, and prompts. Before MCP, every AI integration was bespoke: each app implemented its own way to expose a database to an LLM, its own auth, its own schema. MCP makes that pluggable.

Architecture: client-server with JSON-RPC 2.0 over a transport (stdio, HTTP+SSE, or streamable HTTP). The client hosts the model; the server exposes capabilities. The model decides what to call.

The three primitives (drill these)

1. Tools

Callable functions the model can invoke. Each tool has:

• A name (lookup_sanctions_hit)
• A description (what the model reads to decide when to use it — write it like prompt instructions)
• A JSON schema for inputs (model fills these in)
• A handler that returns content (text, JSON, image, etc.)

Tools are the most common primitive. They're the equivalent of "function calling" / "tool use" in raw LLM APIs, but standardized so the same tool definition works across any MCP-compliant client.

{
  name: 'lookup_sanctions_hit',
  description:
    'Check whether a name or entity matches an active sanctions list (OFAC SDN, EU consolidated, UN). ' +
    'Use this for any KYC review or transaction-counterparty check. ' +
    'Do NOT use this for adverse-media checks — use lookup_adverse_media instead.',
  inputSchema: {
    type: 'object',
    properties: {
      name: { type: 'string', description: 'Full legal name or entity name to screen' },
      jurisdiction: { type: 'string', enum: ['us', 'eu', 'un', 'all'] },
    },
    required: ['name'],
  },
}

2. Resources

Read-only data the model can consult — files, DB rows, documents, URLs. Identified by URIs. The host decides which resources to surface to the model. Resources differ from tools in that they're passive context, not actions.

Examples in compliance:

• compliance://policies/kyc-tier-2.md — a policy doc
• compliance://cases/{case_id}/transactions.json — case-specific data
• compliance://regulations/eu/mica/latest.pdf — current regulation

Why it matters: in regulated contexts, you want the model to reference authoritative documents (and cite them) rather than recalling from training data (which may be outdated or hallucinated).

3. Prompts

Reusable, parameterized prompt templates the server publishes. The user (or agent) selects one and provides arguments.

Example: a "draft SAR narrative" prompt that takes {case_id, suspicious_activity_type, time_window} and returns a fully formatted prompt with the right instructions, examples, and tone.

Prompts are how you ship prompt versioning + governance through the protocol. Compliance loves this: prompts become auditable artifacts, not strings buried in code.

4. Sampling (advanced)

Lets the server request that the client run an LLM completion on its behalf. Inverts the usual flow.

Why it exists: lets MCP servers leverage whatever model the user already has access to (and is paying for) instead of needing their own API key. The server hands a list of messages, optional system prompt, and parameters back through the client; the client runs the completion.

const result = await server.createMessage({
  messages: [{ role: 'user', content: { type: 'text', text: 'summarize this case' } }],
  systemPrompt: 'You are a senior compliance analyst.',
  maxTokens: 4096,
});

Transports

MCP runs over different transports. Know all three:

Design rule: start with stdio for local-only deployments (host spawns the server, OS-level isolation, no network surface). Reach for HTTP when servers need to be remote, multi-user, or share state across clients.

Auth and security — the part most candidates skip

Compliance interviewers care about this more than feature checklists. Even if you've never built an MCP server, you can answer well by reasoning through threat models.

What MCP does NOT specify (historically)

The original spec was deliberately silent on auth. You bring your own. This was a footgun: many early MCP servers required users to paste long-lived service-role keys (or equivalent god-mode credentials) into IDE config files like ~/.cursor/mcp.json, which sit in cleartext on disk inside a third-party app's config.

What good auth looks like

The pattern most teams converge on:

1. Long-lived credential held only in a trusted surface (desktop app, server, secrets manager). Never in IDE config.
2. Short-lived, scoped credential (JWT) minted on demand, scoped to (user_id, project_id, purpose), signed by a server-side secret, TTL minutes-to-days.
3. Server-side validator that checks the JWT and runs every tool operation under the user's identity (so row-level security applies). A compromised JWT only grants what that user already has — not god-mode.
4. Rotation path — revoking the long-lived credential invalidates derived JWTs.
5. Audit logging — every tool call recorded with credential identity, tool, arguments (PII-redacted), result hash.

Other security considerations

• Tool description injection: a malicious server can write a tool description that prompt-injects the model. Defense: pin trusted servers, review tool descriptions, sandbox.
• Confused deputy: an MCP server with broad permissions running on behalf of a less-privileged user can execute privileged actions. Defense: scope auth to user identity, not server identity.
• Sandbox bypass: tools can do anything their handler allows. A read_file tool needs a path allowlist or it becomes a generic file exfil.
• Data classification at the boundary: before returning data from a tool, check whether the requester is authorized to see it.

Building MCP servers — what to know cold

SDKs

• TypeScript: @modelcontextprotocol/sdk
• Python: mcp package — same primitives
• Community: Rust, Go, others

Lifecycle

1. Client launches server (or connects over HTTP).
2. Initialize handshake — client and server exchange capabilities (tools? prompts? resources? sampling?).
3. Client calls tools/list, resources/list, prompts/list to discover.
4. Client invokes (tools/call etc.) as the model decides.
5. Server returns results, including isError: true for tool errors that the model should see.

Error handling at protocol level

• Tool-level errors (isError: true): the model sees the error and can react.
• Protocol-level errors (JSON-RPC error codes): client surfaces to the user.
• Transport errors (connection drop): client retries the session.

try {
  const result = await doTheWork(args);
  return { content: [{ type: 'text', text: JSON.stringify(result) }] };
} catch (err) {
  const message = err instanceof Error ? err.message : 'Internal error';
  return {
    content: [{ type: 'text', text: JSON.stringify({ error: message }) }],
    isError: true,
  };
}

This lets the model see "the lookup_sanctions_hit call failed because X" and try something else, instead of crashing the whole session.

Designing tools well — interview gold

If they ask "how would you design an MCP tool for [compliance task]," structure your answer around these ten principles:

1. Scope narrowly. One tool, one job. Don't build a do_compliance_thing god-tool.
2. Idempotent where possible. Retries shouldn't double-file SARs.
3. Side-effect tools require approval. Tools that write something should return a draft and require a follow-up confirm_* tool.
4. Rich descriptions for model selection. Describe when to use the tool, not just what. Include negative examples.
5. Schema-validate inputs strictly. Models will pass garbage. Reject early.
6. Return structured + human-readable. JSON blob + markdown summary; let the model use either.
7. Bound the output. Don't return 50K tokens of transactions. Paginate or summarize.
8. Log every call. Tool name, args (PII-redacted), result hash, latency, who-called-it. Audit trail starts here.
9. Risk-tier the tool. A lookup_customer tool is low risk. A freeze_account tool is high risk. Different gates.
10. Version the schema. Tool changes break agents. Adopt semver in tool names or descriptions.

n8n and MCP — where they meet

Recent n8n versions have an MCP Client node and ways to expose n8n workflows as MCP servers. This means:

• Your agent (Claude API + MCP client) can call n8n workflows as tools.
• n8n becomes the visible audit/approval layer; the agent calls in.
• Or: an n8n workflow uses an MCP client node to call out to your custom servers.

Likely interview probes — with strong answers

Structure for each: short claim → why → concrete example. Don't memorize verbatim; internalize the shape.

Cheat sheet — terms to use confidently

• Host / Client / Server — the host app contains the client, which connects to one or more servers
• Capabilities — what the server advertises during init (tools? prompts? sampling?)
• Tool call / tool use trace — the sequence of model → tool → result → model exchanges
• Resource subscription — clients can subscribe to resource changes (the server pushes updates)
• Prompt argument — parameters in a prompt template
• Roots — workspace dirs or URLs the client tells the server are "in scope"
• Notifications — server-pushed messages (resource changed, log line) outside request/response