AIML Rounds
Concept20 minBefore this:Tool and Function Calling

MCP: The Model Context Protocol

What is MCP, and how is it different from function calling?

The situation

The company wants its order system usable from the refund agent, the internal support chat, agents in the IDE and a few vendor tools, without a separate integration for each. A colleague suggests MCP, and says that also makes it safe. The interviewer asks:

What is MCP, and how is it different from function calling?

Running example: the company wants its order system usable from the refund agent, the internal support chat, agents in the IDE and a few vendor tools, without writing a separate integration for each.

Every app × every tool

Before MCP, each AI application defined its own plugin or tool format, so connecting a data source meant writing and maintaining an adapter per application. Tool providers repeated the work for every host; hosts repeated it for every tool.

The idea

Think of USB-C. Before it, every device needed its own cable for every charger. A standard port means each device and each charger is built once. But a standard port tells you nothing about whether that charger is safe to plug in.

MCP 10 apps × 20 tools = 200 integrations10 clients + 20 servers = 30 Apps on the left of each diagram, tools on the right
From the lab: integration pieces to build and maintain.

Play

Try to break it. Change the number of AI applications and the number of tools, and watch how far apart the two counts get.

Count the integrations

Custom glue for every pair

custom integrations (N × M)
–
with MCP (N clients + M servers)
–
fewer pieces to build
–

Counts integration components to build and maintain; ignores per-integration size.

With 10 AI applications and 20 tools, custom integrations mean 200 adapters to build and keep working; with MCP, 10 clients (usually built into the host) and 20 servers: 30, 6.7× fewer, and the gap grows with both numbers. The trap is assuming standard plumbing means safe plumbing: anyone can publish a server, and a server's tool descriptions go straight into the model's context.

Now say why: the model still emits tool calls, so what has MCP actually standardised?

How it works

In one breath

Every AI app (chat assistant, IDE, agent) wants to connect to every tool and data source (GitHub, Slack, databases, your order system). Without a standard, that's N apps × M tools custom integrations. The Model Context Protocol, introduced by Anthropic in Nov 2024 and since adopted widely (and donated to the Linux Foundation's Agentic AI Foundation in Dec 2025), standardises the connection: a tool provider writes one MCP server; any MCP-capable host connects to it through a client, so it's N + M. Servers expose tools (actions the model can call), resources (data to read) and prompts (templates); messages are JSON-RPC 2.0 over stdio (local) or Streamable HTTP (remote, with OAuth). MCP doesn't replace function calling; it's how the tools get discovered and invoked across apps. The spec is versioned by date and changes often, so check the current revision.What you'll be able to do after this: explain MCP's architecture and primitives, compare it with function calling, and name its security risks.
host / clientMCP serverstandard integrationcustom gluenumbers

Hosts, clients, servers and primitives

  • Host: the AI application (a desktop assistant, IDE, agent runtime). It runs one client per connected server and decides what the model sees and is allowed to do.
  • Server: a program exposing capabilities. Tools (model-invoked actions with JSON-schema inputs), resources (readable data, by URI), prompts (reusable templates the user can pick).
  • Client features: servers can ask the host for sampling (an LLM completion), roots (allowed directories) and elicitation (asking the user for input).
  • Protocol: JSON-RPC 2.0 messages: initialize (capability negotiation), tools/list, tools/call, resources/read, notifications for changes.
  • Transports: stdio for local servers launched by the host; Streamable HTTP for remote servers (replaced the older HTTP+SSE transport in the 2025-03-26 revision), with OAuth-based authorisation.

The spec is dated: 2025-03-26 (Streamable HTTP, OAuth 2.1 authorisation), 2025-06-18 (elicitation, structured tool output), 2025-11-25 (experimental tasks, authorisation updates), with later revisions continuing. Treat feature lists as "check the current revision".

In practice

Security and practice

  • Tool poisoning: malicious instructions hidden in a server's tool descriptions (which the user rarely sees) can steer the model; a server can also change its tools after you approved it ("rug pull"). Pin and review server versions; show users what tools do.
  • Over-broad permissions: a server with full repo or database access is a powerful exfiltration channel if combined with untrusted content (lethal trifecta). Use least-privilege tokens, OAuth scopes and per-tool approval.
  • Too many servers: every connected server adds tool definitions to context; enable only what the task needs, or use tool search (tool calling).
  • Ecosystem: official SDKs in many languages, registries of servers, and support across major assistants, IDEs and agent frameworks. Related protocols: A2A (agent-to-agent) addresses agents calling other agents rather than tools.
One sentence

A USB-C port for AI tools

MCP turns N × M custom integrations into N + M standard ones by defining how hosts discover and call tools, read resources and use prompts, while trust, permissions and context budget remain the host's job.

The answer that sounds right

"MCP makes tools safe"

It sounds right, since standards tend to feel safer. But it standardises access, and security is still yours. Anyone can publish a server, its tool descriptions go straight into the model's context, and a server can change its tools after you approved it. So pin servers, scope tokens and require approval for sensitive tools. It doesn't replace APIs either: servers usually wrap them.

Say it

What is MCP, and how is it different from function calling?

Say your answer out loud

Aim for 30 seconds. It feels different from reading it, and that's the point.

Tick what you covered

The interviewer pushes further

Follow-up 1 of 3

MCP vs function calling?

Answer it out loud, then check.

Function calling is how a model requests a tool call in one API; MCP is how tools are packaged, discovered and invoked across many hosts. A host typically converts MCP tools into the model's function-calling format.

Follow-up 2 of 3

Tools vs resources vs prompts?

Answer it out loud, then check.

Tools are model-controlled actions; resources are application-controlled data the host can include in context; prompts are user-selected templates.

Follow-up 3 of 3

How would you expose your order system via MCP safely?

Answer it out loud, then check.

A remote server with OAuth, read-only tools by default, a narrow refund tool with server-side limits and idempotency, audit logs, and human approval above a threshold.

The 30-second answer

MCP is an open protocol, started by Anthropic and now under the Linux Foundation, that standardises how AI applications connect to tools and data. A host runs a client per server; servers expose tools the model can call, resources it can read and prompt templates, over JSON-RPC via stdio locally or Streamable HTTP remotely with OAuth. It turns N times M custom integrations into N plus M. It complements function calling rather than replacing it: the model still emits tool calls, MCP standardises discovery and execution. The main risks are untrusted servers, poisoned tool descriptions and over-broad permissions, so pin servers, scope tokens and require approval for sensitive tools.

Go further

What not to say

  • "MCP makes tools safe." It standardises access; security is still yours.
  • "MCP replaces APIs." Servers usually wrap existing APIs.

Key terms and sources

What MCP is and why it spread: the N×M integration problem, hosts, clients and servers, the primitives (tools, resources, prompts; and client features like sampling and elicitation), JSON-RPC messages, transports (stdio, Streamable HTTP), authorisation, how MCP relates to plain function calling, security concerns, and how the dated spec evolves · built from the Model Context Protocol specification and changelogs (modelcontextprotocol.io), Anthropic's MCP announcement (Nov 2024), the Linux Foundation Agentic AI Foundation announcement (Dec 2025), and the OWASP and Invariant Labs analyses of MCP tool poisoning · checked 29 Oct 2026

Sources

  1. Model Context Protocol specification, revisions and changelog, modelcontextprotocol.io; GitHub releases.
  2. Anthropic, "Introducing the Model Context Protocol", Nov 2024.
  3. Linux Foundation, announcement of the Agentic AI Foundation (MCP contributed by Anthropic), Dec 2025.
  4. Invariant Labs, "MCP Security Notification: Tool Poisoning Attacks", 2025; OWASP GenAI Security Project guidance on agentic applications.