How does MCP differ from OpenAI's function calling? Why is a protocol needed on top of it?

Function calling is a model-level feature: the LLM outputs structured JSON saying "I want to call function X with arguments Y." But it doesn't define how to discover those functions, how to execute them, how to authenticate, or how to manage the connection to the system that implements them. The developer must write all that glue code — custom for each tool, each model, each application. MCP standardizes everything around the function call: discovery (tools/list), execution (tools/call), session management (initialize/shutdown), transport (STDIO/HTTP), and auth (OAuth 2.1). Think of it this way: function calling is the LLM saying "I want to call create_issue." MCP is the protocol that makes that call actually reach the Sentry API, authenticated, with the right arguments, and returns the result. Without MCP, every developer writes their own version of this plumbing. With MCP, they implement it once.

Why is MCP stateful? Couldn't you make it stateless like REST for simplicity?

Statefulness is required for three features: (1) Capability negotiation: the client learns the server's capabilities once at initialization. With REST, you'd need to send capabilities with every request or make a separate discovery call before every interaction — wasteful. (2) Subscriptions: a client can subscribe to resource changes and receive push notifications. This requires a persistent session. Stateless REST can't do server-initiated messages. (3) Server-side session state: a database MCP server might maintain a transaction across multiple tool calls. "Begin transaction → INSERT → SELECT → COMMIT" is inherently stateful. The tradeoff: stateful servers are harder to scale horizontally (session affinity required) and harder to recover from crashes (session state is lost). MCP accepts this tradeoff because the interaction model — an AI agent using tools in a conversation — is inherently session-scoped.

What prevents a malicious MCP server from tricking the LLM into harmful actions?

This is the biggest security challenge in MCP and it's addressed through defense in depth, not a single mechanism. Layer 1: Host mediation — the LLM never communicates directly with servers. Every tool call goes through the host controller, which can approve, deny, or modify it. A policy like "require human confirmation for any tool that sends data externally" catches most attacks. Layer 2: Tool annotations — servers declare whether tools are read-only, destructive, or external-facing. The host uses these to calibrate approval requirements. Layer 3: Tool result handling — results from servers are injected as tool-result content, not system instructions. Well-trained LLMs treat tool results as data, not instructions. Layer 4: Server isolation — tools from one server can't directly access another server's resources. The honest answer: prompt injection via tool results is an unsolved problem in the field. MCP's architecture minimizes the attack surface (host mediation is the key), but a sufficiently clever injection in a tool result could still influence the LLM. This is an active area of research.

How does MCP relate to LSP? What lessons were borrowed?

MCP is architecturally inspired by LSP (Language Server Protocol), which solved the same M×N problem for IDE tooling. Before LSP: every IDE (VS Code, IntelliJ, Vim) needed a custom plugin for every language (Python, Rust, Go). LSP created a universal protocol: one language server per language, one LSP client per IDE. M+N instead of M×N. MCP borrows: (1) JSON-RPC 2.0 as the wire format — proven, simple, language-agnostic. (2) Capability negotiation at initialization — the same pattern where client and server exchange what they support. (3) Stateful sessions with explicit lifecycle — initialize, active, shutdown. (4) The client-server-host separation of concerns. What MCP adds beyond LSP: OAuth authentication (LSP servers are local-only), Streamable HTTP transport (LSP only uses STDIO), tool annotations (LSP doesn't have action safety metadata), and sampling (servers requesting LLM inference — no LSP equivalent). The success of LSP (adopted by virtually every IDE and language) is the strongest evidence that this architectural pattern works for standardizing M×N ecosystems.

How would a popular remote MCP server (like Notion) scale to millions of concurrent sessions?

MCP sessions are stateful (capabilities, auth context, subscriptions), which means the server must maintain per-session state. At millions of sessions, this is a stateful server scaling challenge. Two approaches: (1) Session affinity: the load balancer hashes the Mcp-Session-Id header to route all requests for a session to the same server instance. Session state lives in the server's memory. Simple, but a server failure loses all its sessions (clients must re-initialize). (2) Externalized state: store session state in Redis or a similar shared store. Any server instance can handle any request — truly stateless servers with shared session state. More complex but more resilient. In practice, MCP sessions are lightweight: a capabilities object, an auth token, and a list of subscriptions. This fits easily in a few KB per session. A single Redis cluster holding 10M sessions × 5KB = 50GB — very feasible. The heavy part is the actual tool execution (calling Notion's API), which is the server operator's existing scaling problem — MCP doesn't make it worse.