Function calling is how a single AI model asks your code to run a tool. MCP, the Model Context Protocol, is an open standard for packaging those tools (plus data and prompts) in a server that any compatible AI app can connect to. Function calling is the mechanism; MCP is the plug. You still use function calling under the hood, but MCP means you build an integration once and use it from Claude, ChatGPT, your IDE and your own agents instead of rewriting it for each one. This guide explains both, how they differ, and when you actually need an MCP server.
What Is Function Calling?
Function calling (also called tool calling or tool use) is a feature of model APIs. You describe the functions your application offers, each with a name, a description and a JSON schema for its inputs, and send them with the request. When the model decides a function would help, it returns a structured call such as get_order_status({"order_id": "A1042"}) instead of plain text. Your code runs the function and sends the result back, and the model uses it to answer.
Every major provider supports it, including OpenAI function calling and Anthropic tool use. The key point is that the tool definitions and the code that runs them live inside your application. They are wired to one app and usually to one provider’s request format.
What Is MCP (Model Context Protocol)?
The Model Context Protocol is an open standard, introduced by Anthropic in late 2024 and now supported across the industry, for connecting AI applications to external systems. It defines three roles:
- Host: the AI application the user works in, such as Claude, ChatGPT, an IDE or your own agent.
- Client: the connector inside the host that speaks MCP.
- Server: a small service you build that exposes your system’s capabilities.
An MCP server can offer three kinds of things:
- Tools: actions the model can call, like “create invoice” or “search tickets”.
- Resources: data the application can read, like files, records or documentation.
- Prompts: reusable templates for common tasks.
Servers run locally over standard input and output, or remotely over HTTP with authentication. Once your server exists, any MCP-compatible host can discover its tools and use them, with no custom integration code per host.
MCP vs Function Calling: The Key Differences
| Feature | Function calling | MCP |
|---|---|---|
| What it is | A model API feature | An open protocol between AI apps and tool servers |
| Where tools live | Inside your application code | In a separate MCP server |
| Reuse | One app, often one provider format | Any MCP-compatible host or agent |
| Discovery | You send tool definitions with each request | Hosts ask the server which tools it offers |
| Beyond tools | Tools only | Tools, resources and prompts |
| Auth and permissions | Your app handles it | Defined by the protocol, OAuth for remote servers |
| Best for | A single product with its own AI feature | Tools shared across many AI apps, teams or customers |
They are not competitors. When Claude uses a tool from an MCP server, the model still makes a tool call; MCP standardises how that call reaches your system and how the tool was discovered in the first place.
How a Request Flows Through Each
With Function Calling
- Your app sends the user’s message and the tool definitions to the model.
- The model returns a tool call.
- Your app runs the function against your database or API.
- Your app sends the result back; the model writes the answer.
With MCP
- The host connects to your MCP server and lists its tools.
- The host passes those tools to the model with the user’s message.
- The model returns a tool call; the host forwards it to your MCP server.
- Your server runs it and returns the result; the model writes the answer.
The model-facing step is identical. What changes is who owns the tool code and how many applications can use it.
When You Need an MCP Server
Build an MCP server when:
- You want your product usable from Claude, ChatGPT or IDE assistants. A SaaS company can publish an MCP server so customers ask their AI assistant to work with their account.
- Several internal agents need the same tools. Build “search CRM” and “create ticket” once and share them with every agent and every team.
- You want to switch models or frameworks freely. MCP tools work with LangGraph, the OpenAI Agents SDK, the Claude Agent SDK and many others, as compared in our agent framework guide.
- Staff use AI desktop apps daily and you want those apps to reach internal data safely, with permissions you control.
Real-World MCP Server Examples
- CRM access for a sales team: tools to look up a contact, list open deals and log a call, so reps can ask Claude or ChatGPT “what happened with this client last month” and update records from the same chat.
- Internal knowledge: a resource and search tool over policies and documentation, used by every internal assistant instead of each one building its own retrieval.
- SaaS product integration: a public MCP server that lets customers manage their account in your product from their own AI assistant, for example creating a report or checking usage.
- Engineering workflows: tools to query error logs, read deployment status or open tickets from inside an IDE assistant.
- Operations: read-only tools over inventory, bookings or fleet data, so managers can ask questions in plain language without a new dashboard.
Local vs Remote MCP Servers
MCP supports two main ways to run a server, and the choice affects security and distribution.
| Feature | Local server | Remote server |
|---|---|---|
| Transport | Standard input and output, started by the host | HTTP (Streamable HTTP) |
| Runs on | The user’s own machine | Your cloud |
| Authentication | Inherits the user’s local access | OAuth, per user |
| Good for | Developer tools, files on a laptop, personal use | Business systems, SaaS products, shared team tools |
| Distribution | Each user installs and configures it | Users add a URL and sign in |
For business systems, a remote server is almost always the right choice: credentials stay on your side, access is per user and you can update the server without asking anyone to reinstall it.
How to Build an MCP Server, Step by Step
- Pick the jobs, not the endpoints. List the five to ten things users actually want an AI to do in your system. Design tools around those tasks rather than mirroring every API endpoint.
- Write excellent tool descriptions. The model chooses tools from their names, descriptions and input schemas. Clear, specific descriptions improve accuracy more than any other change.
- Use an official SDK. The TypeScript and Python SDKs handle the protocol, so your code focuses on business logic.
- Add authentication and permissions. Map every call to a real user and check what that user is allowed to do.
- Test with real hosts and a test set. Try the server from Claude, ChatGPT and your own agent with realistic requests, and keep the requests as a regression suite.
- Log and monitor. Record each tool call and watch for errors, slow tools and unexpected usage.
When Plain Function Calling Is Enough
- You have one application with one AI feature and no plans to reuse the tools.
- Latency is critical and an extra network hop matters.
- The tools are tightly bound to your app’s internals, such as the current user’s session state.
Plenty of excellent AI features are built this way. You can always extract the tools into an MCP server later.
Moving Existing Function Calls to MCP
If your product already uses function calling, you do not need to start again. The tool definitions you send to the model today, a name, a description and a JSON schema, map almost directly onto MCP tools. A typical migration looks like this:
- Move the functions behind your tools into a separate service, or a separate module that the MCP SDK can wrap.
- Register each one as an MCP tool, reusing the existing names, descriptions and schemas.
- Replace per-request API keys with per-user authentication, so the server knows who is calling.
- Point your own application at the MCP server as a client, so your product and external AI apps share exactly the same tools.
The benefit compounds over time. Every new tool you add appears in your own product, in Claude, in ChatGPT and in your internal agents at once, and fixes or permission changes happen in one place.
Cost and Performance Trade-offs
MCP itself adds little cost: a small server, usually on infrastructure you already run. The bigger effect is on the model side. Every tool a host loads is described to the model in each request, which uses tokens and can make tool choice less accurate. Expose a focused set of well-described tools rather than hundreds, and group rarely used ones into a separate server that users enable only when they need it. A remote server also adds a network hop to each tool call, which is negligible for most business tasks but worth measuring in latency-sensitive features such as voice agents.
Security Considerations for MCP
An MCP server is an API that an AI can drive, so treat it with the same care as any public API, and more:
- Least privilege. Expose only the tools you need, and scope each to the user’s own permissions.
- Authentication. Use OAuth for remote servers, as the MCP specification describes, never shared static keys.
- Confirm destructive actions. Deleting, paying or sending should require explicit confirmation.
- Watch for prompt injection. Content returned by tools, such as an email body, can contain instructions aimed at the model. Treat it as data and limit what follow-up actions it can trigger.
- Log everything. Record every tool call with its inputs, user and outcome.
We design these controls into every MCP server we build, and into the AI agents that use them.
FAQ
Is MCP replacing function calling?
No. MCP builds on function calling. The model still issues tool calls; MCP standardises where the tools live and how applications discover and call them, so one integration works across many AI apps.
Does ChatGPT support MCP?
Yes. OpenAI supports MCP in its products and developer platform, alongside Claude, Microsoft and Google tools and many IDEs. Support details change quickly, so check each host’s current documentation for remote server and authentication options.
How long does it take to build an MCP server?
A focused server that exposes a handful of tools from one system typically takes two to four weeks including authentication, permissions and testing. With EqualPixels, MCP server projects typically start at about $4,000.
Can an MCP server expose a database?
Yes, but avoid giving the model raw query access. Expose specific, well-described tools such as “find customer by email” or “list overdue invoices”, each with permission checks. It is safer and the model uses narrow tools more accurately.
What languages can I build an MCP server in?
Official SDKs exist for TypeScript, Python and several other languages, including Java, C# and Go. Choose the language your team already uses for the system you are exposing.