Course Content
Agents & Tools Interview Prep
6 sections · 40 lessons
How does MCP differ from traditional function calling approaches?
What you need to know
| Native function calling | MCP | |
|---|---|---|
| Layer | Model API feature | Protocol between app and tool server |
| Tool definitions | Written in your app's code | Fetched from the server at runtime |
| Where tool code runs | In your app | In the server process |
| Reuse | One app | Any MCP-compatible host |
| Adding a tool | Redeploy the app | Update the server only |
| Auth | Your app's credentials | Server's own auth (OAuth for HTTP) |
| Latency | In-process call | Extra IPC or network hop |
How they combine
- Host lists tools from each MCP server.
- Host converts them into the model API's
toolsformat. - Model emits a normal tool call (
tool_use,function_call). - Host routes the call to the right MCP client, which sends
tools/call. - Host returns the MCP result as a normal tool result.
The provider-side shortcut
Some model APIs can act as the MCP client for you. With Anthropic's MCP connector (a beta feature), you pass mcp_servers (URL, name, optional token) and a matching mcp_toolset entry in tools; the API connects to the remote server, lists tools and calls them during the response. This saves writing a client, but the server must be reachable from the provider, and you lose the chance to validate or approve each call in your own code — so it suits read-only or low-risk servers.
Honest trade-offs
- For three internal functions used by one app, plain function calling is simpler and faster.
- For integrations shared across apps or teams, or supplied by vendors, MCP saves repeated work.
- MCP servers are third-party code or services; review and pin them like any dependency.
A real-life example
A bank's customer assistant has two kinds of tools.
Core banking tools — get_balance, list_transactions, create_transfer. They are written by the assistant team, need tight latency, and every call goes through a confirmation and fraud check in the same service. These stay as native function calls in the assistant's code.
Knowledge tools — search the policy wiki, look up branch timings, read the fee schedule. Four other internal apps need the same tools. The knowledge team publishes them as one MCP server. The assistant lists them at start-up and passes them to the model with the native tools. The model sees seven tools and cannot tell which are MCP.
When the fee schedule tool gains a new product_type filter, only the knowledge team deploys. The assistant team does nothing.
Follow-up questions to expect
- "Can one agent mix native tools and MCP tools?" — Yes, and that is common. To the model they are all just tools.
- "Does MCP replace OpenAPI?" — No. An MCP server often wraps a REST API; MCP adds model-friendly descriptions, discovery and a standard result shape.
- "What does MCP cost at runtime?" — One extra hop per call (small for stdio, a network round trip for HTTP) and some start-up time for discovery.