How are MCP and function calling different?
Function calling lets a model request an operation with structured arguments. MCP connects an AI host to a server that exposes tools. They often work together: the host maps a model’s request to an MCP tool invocation, executes it under the caller’s permissions and returns the result. Choose MCP when that shared server interface saves integration work.
Last verified: November 3, 2026.
The confusing part is that both interfaces describe tools. Each may include a name, a description and an input schema. Similar-looking JSON does not mean they own the same work. The model requests an action. The surrounding software decides whether and how to execute it.
Anthropic’s tool-use contract makes that split explicit: the model emits a structured request, execution happens in code or a provider-operated tool service, and the result returns to the conversation. MCP can supply the server interface used by that execution code.
Follow a ticket search through the complete loop
An employee asks, “Find my open support tickets.” Assume a reviewed server exposes search_tickets and the employee is allowed to use it.
The host first obtains the tools available to this caller. It adapts the relevant definitions into the selected model provider’s tool format. The model can then request search_tickets with arguments such as a status filter.
Before execution, the host validates the requested name and arguments and applies its own controls. Its MCP client invokes the server. The server checks the caller’s rights and reaches the ticket system using the configured downstream identity. The host receives the result and passes the appropriate content back to the model for an answer.
Employee request
-> host supplies permitted tool definitions to the model
-> model requests search_tickets with structured arguments
-> host validates and authorizes the request
-> MCP client invokes the reviewed server tool
-> server calls the ticket API under approved credentials
-> host maps the tool result back to the model
-> model writes an answerThe MCP architecture defines the host/client/server relationship. The host owns the model integration; the server supplies capabilities. For the API behind the ticket server, see MCP vs REST API.
Compare what each layer owns
The useful question is where a responsibility belongs, rather than which label has more features.
| Attribute | Function calling in an application | MCP client/server layer |
|---|---|---|
| Main job | Let the model request a structured operation | Discover and invoke capabilities through a shared protocol |
| Tool definitions | Adapted to the model provider’s request format | Exposed by the server and selected by the host |
| Execution owner | Application code or a provider-operated tool service | MCP server and the systems it calls |
| Deployment model | Part of the application/tool execution design | Local process, remote service or gateway-backed servers |
| Identity and access control | Application binds requests to its caller and policy | Server/gateway authenticates and authorizes the invocation |
| Audit logging | Model request, application decision and execution records | Correlated protocol, server and destination records |
| Supported MCP transports | No MCP binding required for direct execution | Standard bindings include stdio and Streamable HTTP |
| Hosting | Application environment and selected model service | Local machine, your platform or a managed service |
MCP’s transport overview describes the standard bindings. Verify the actual host supports the required server features and protocol revision; sharing the word MCP on two product pages is an incomplete compatibility check.
What does the adapter between the two need to do?
It needs to preserve the meaning of the tool definition and result. Name mapping alone is insufficient if one interface represents results, errors or optional fields differently.
For a simple application, that bridge might follow this pseudocode:
available = discover_tools_for(authenticated_caller)
model_tools = adapt_definitions(available)
request = ask_model(user_message, model_tools)
for each requested_operation in request:
validate_name_and_arguments(requested_operation, available)
enforce_user_policy(authenticated_caller, requested_operation)
obtain_required_approval(requested_operation)
result = invoke_mcp_tool(requested_operation)
append_model_compatible_result(result)Production code also needs limits, timeouts and recovery behavior. If the model requests several operations, decide which may run in parallel and which depend on earlier outcomes. If the server returns an error, preserve that outcome rather than wrapping it as a successful response.
The MCP tools specification describes tool discovery, calls and result handling. A host’s provider adapter must map those to its own model interface; clients can differ in the subset they expose.
Keep permissions outside the model’s judgment
An instruction saying “only leads may update tickets” is useful context, but the execution layer needs to enforce the rule. A support employee’s valid request to update_ticket_status must fail before the destination changes anything.
Validate the caller from trusted authentication state. Do not trust a model-generated acting_user argument to select credentials. Keep the authenticated subject, the requested action and the downstream identity visible to the policy decision.
The per-user MCP access-control guide gives a concrete permission matrix. If the MCP server is remote, the OAuth setup guide covers authentication and the separate downstream credential. A local subprocess needs its own credential and execution review.
A schema can verify that ticket_id is a string. It cannot establish that the employee owns that ticket or that changing its status is appropriate. Keep those checks in the service and workflow. For changes requiring human approval, bind approval to the exact operation and arguments that will execute.
Review descriptions as well as code. An altered tool definition can influence which action the model requests even when its input schema stays unchanged. Our tool-poisoning change-review guide covers that release boundary. Instructions distributed through a SKILL.md file also need review; they do not grant server permissions.
When is direct function calling enough?
Direct execution can be a good fit for one application with a few stable operations. The application already knows the business APIs, and its owners can maintain the tool definitions, permissions and result handling in the same codebase.
MCP becomes attractive when several compatible hosts need the same server-maintained tool interface. The server team can publish one implementation, and each host maintains its MCP integration and model mapping. That can reduce repeated work while adding a protocol and deployment boundary to support.
Compare a small change before committing. Add one field to the ticket-search result and change one permission. In a direct design, which applications need an update? In the MCP design, which servers, clients and model adapters need testing? That exercise exposes the actual maintenance trade more clearly than counting supported tools.
MCP also does not select a model provider. If you need routing or spending controls for model requests, use the separate LLM gateway vs MCP gateway comparison.
What should you test before sharing the server?
When several teams share the same server, the open source MCP gateway comparison can help shortlist an enforcement point. Run the host’s complete execution loop through that candidate, including how a denial reaches the model.
Run one permitted search, one forbidden write and one destination error through the complete model-to-tool loop. Check the final answer as well as the protocol result: the assistant should not claim the update succeeded after a denial.
Then change an input schema or tool name in a test release. Confirm that supported clients refresh the definition and stop offering retired behavior. Keep the approved release and owner in a private MCP registry.
Record a correlation identifier across the model request, host decision and server outcome. Our MCP audit-evidence guide explains how to verify coverage. The gateway guide places a shared enforcement layer in that path when several teams need one.
ASCENDING builds Jarvis. The Jarvis MCP gateway is relevant to the shared tool-access layer. Include your host’s model adapter in any trial so the demonstration proves the full loop employees will use.
References
- Anthropic: how tool use works
- MCP architecture
- MCP tool definitions, calls and results
- MCP transport bindings
MCP and function calling questions
What is the difference between MCP and function calling?
Function calling is the model-facing mechanism for requesting a named operation with structured arguments. MCP is the interface between an AI host's client and a tool server. The host can translate a model's function request into an MCP tool call, then return the result to the model.
Does MCP replace function calling?
No. The two often work together. MCP can provide tool discovery and execution while the model still uses its provider's tool-calling format. The host handles the mapping, permissions and result processing.
Can I use function calling without an MCP server?
Yes. Your application can validate the model's request and call a local function or an API directly. That is often a reasonable design for one application with a small set of tools. MCP is useful when a shared server interface reduces repeated integration work across compatible clients.
Does a valid tool schema make a call safe?
No. A schema constrains the shape of arguments. The execution layer still needs authorization, business validation, record access controls and any required human approval. A well-formed request can still ask for an operation the caller must not perform.
