MCP vs Function Calling: Different Layers, Often Used Together

Your application defines a function/tool schema, sends it with the model request, receives a structured call, validates the arguments, executes code or an API, and returns the result. This is a good fit for a small number of application-owned capabilities where provider coupling and custom lifecycle code are acceptable.

An MCP host connects to servers, discovers tools/resources/prompts, and invokes them through the protocol. The server can be local or remote and can serve multiple compatible hosts. You still need application logic to decide which discovered tools reach the model and how approval, errors, and results map to the chosen provider.

For `lookup_order`, direct function calling defines the schema in the model request and executes a local handler. Through MCP, an order server advertises the tool; the host adapts that schema to the model provider; the model selects it; the host sends `tools/call`; and the server calls the same downstream order API. The underlying business function can be identical while the discovery and operational boundary changes.

Use direct function calling for application-owned functions with no cross-host reuse requirement. Use MCP when external capability teams need a standard server boundary or multiple compatible hosts should reuse the integration. Use both when the host's model API uses function calling to select tools that were discovered through MCP—which is a common composition, not a contradiction.

Direct calling has fewer protocol participants but leaves discovery, auth, versioning, and adapters in the application. MCP adds a connection, lifecycle, and server deployment boundary but can consolidate reusable capability logic. Measure setup, schema translation, context size, latency, authorization, observability, and failure recovery in your own stack before claiming a portability or performance win.