MCP vs function calling
“How does MCP relate to native function calling, and when would you use one, the other, or both?”
What this tests
- Understanding that MCP sits on top of function calling, not beside it
- Clear decision criteria: number of hosts, ownership, trust, latency
- Operational awareness: process boundary, versioning, discovery
- Recognising that most small systems do not need MCP
Answers by level
Read the beginner answer first and notice what is missing.
They are different layers. Function calling is the model capability: the model receives tool schemas and emits structured calls. MCP is a protocol for how a host application discovers and invokes tools from external servers; when the host gets a tool list from an MCP server, it still presents those tools to the model via function calling. MCP does not replace function calling; it feeds it. See MCP vs Direct Integration vs Function Calling.
Direct function calling with in-process handlers is right when you own the integration, it serves one application, and you want the lowest latency and simplest security model. MCP is right when capabilities should be shared across hosts, provided by other teams or vendors, or discovered at runtime. Both together is the common production shape: a few critical in-process tools plus MCP servers for shared or third-party capabilities.
Costs of MCP: a process or network hop per call, server lifecycle management, version skew between server and host, and trusting server-supplied descriptions.
Green flags · Red flags
- MCP is a layer above function calling, not a replacement
- Criteria: ownership, number of hosts, third-party ecosystem
- Names latency overhead, versioning, lifecycle costs
- Curated allowlist and tool filtering
- Treats server descriptions and results as untrusted
- Says MCP replaces function calling
- Uses MCP by default for a single-app integration
- No mention of security or trust boundary
- No operational considerations