MCP and Tool Integration Protocols

Every agent that does more than talk needs to reach outside the model: a database, a ticket tracker, an internal API, a filesystem, a search index. The naive way to build that is what most teams did for the first couple of years of the LLM tool-use era — write a function schema, wire it to a handler, ship it inside the one application that needs it. That works fine for one app and one integration. It stops working the moment a second application wants the same database connector, or a third-party team wants to expose a data source to any agent without shipping custom glue for each one. The industry's answer was to standardize the wire format for "agent talks to external system" the same way HTTP standardized "browser talks to server" — a protocol, not a library, so that any compliant client can speak to any compliant server without either side knowing the other exists in advance. The Model Context Protocol (MCP) is the standard that emerged for this, and it's now supported across multiple agent hosts and vendors — which is exactly why it's the kind of foundational, ecosystem-level decision interviewers ask about, rather than a single product's feature.

This subject is the conceptual and comparative layer: why a standard protocol exists at all, what its abstractions mean architecturally, how it differs from — and builds on — plain function calling, and what trust boundary it introduces. It is deliberately vendor-neutral and framed around how you'd reason about this in an interview, not around any one product's configuration syntax. For the concrete, hands-on version of this — actually connecting an MCP server, watching discovery and invocation happen, and the specific mechanics of scoping credentials — see mcp-and-subagents, which walks through a database MCP server end to end inside Claude Code. Read that subject for the "how do I actually do this" layer; this one is the "why does this exist and how do I talk about it" layer, and the two are meant to be read as a pair.

A fair interview question here is not "what is MCP" as trivia. It's "why would a team adopt a protocol instead of just writing functions," "what does that decision cost and buy you," and "what changes about your security posture once a tool can come from a third party you don't control." Those are design questions, and they're now common enough — MCP has become the de facto standard tool-integration layer across multiple agent platforms — that being unable to reason about them, distinct from being unable to reason about function calling itself, is a real gap. This subject also matters because it sits at the intersection of two things interviewers probe separately: protocol/systems-design thinking (why does a standard exist, what does it trade off) and security thinking (what changes once code you didn't write gets runtime access). Being fluent in both, together, is what separates "I've used MCP" from "I understand why it exists."