Choosing between MCP, function calling, and policy runtimes

These three terms get conflated. They solve different problems, at different layers, and you usually want at least two of them. A practical disambiguation.

When teams ask “should we use MCP?” or “is function calling enough?” they’re usually asking about three different concerns at once. This article disambiguates.

The three things

Function calling is a model interface. It’s the format in which an LLM provider receives tool definitions and emits tool-invocation requests. OpenAI, Anthropic, and Google all support some flavor of it. The provider parses the tool definitions, the model emits a structured tool call, the application executes it, the result goes back into the conversation.

MCP (Model Context Protocol) is a transport and discovery protocol. It standardizes how an external server can expose tools, prompts, and resources to an MCP-aware client (Claude Desktop, Cursor, custom clients). The client discovers tools from the server and feeds them into the model’s function-calling interface.

Policy runtimes are an enforcement layer around tools. They control what tools do, who can call them with what arguments, and what gets logged. OrmAI is a policy runtime.

These are three different things and you usually want all three:

The model needs an interface to call tools (function calling).
The tools need a way to be discovered and reached (MCP, or your own API, or an SDK like Vercel AI SDK).
The tools need policy enforcement (a policy runtime).

Why they get conflated

A naive MCP database server combines “MCP transport” with “tool definition” with “no policy at all.” It looks like a complete agent–database story because all three concerns are bundled. They are bundled badly: the policy story is “the database role you connected with is your policy.”

Similarly, hand-rolled function-call tools combine “interface” with “implementation” with “ad hoc policy embedded in code.” It looks complete because all three are in one file. The policy story is “whatever the function does, plus whatever validation we remembered to add.”

You don’t see the gaps until you scale (more tools, more tenants, more compliance) or get audited.

When you need each layer

You always need function calling

It’s the API. The model has to be able to call your tools. There’s no choice about this; the only question is which provider’s flavor you’re using.

You need MCP if…

Your tools should be reachable from external clients (Claude Desktop, Cursor, third-party agents).
You want a standard protocol that future AI clients can target.
You’re building developer tooling that another team will integrate with.

You don’t need MCP if:

Your agent is hosted in your own application and calls tools in-process.
Your tools are domain-specific to your product and not useful to external clients.

For a typical SaaS product with an in-app agent, you probably don’t need MCP. For an open developer tool, you probably do.

You always need a policy runtime if you have multiple tenants, PII, or writes

This is the surprising one for many teams. A policy runtime isn’t optional for production systems with any kind of sensitive data. It can be:

A library like OrmAI.
A bespoke implementation if you have unusual requirements.
A homegrown layer that started as “we’ll just add some checks” and grew up.

The point is that the rules — tenant scoping, redaction, budgets, audit — should live in one layer that wraps all your tools, not be re-derived per tool. The policy runtime is the thing that wraps.

For a single-developer dev-tool agent, you can skip it. For a multi-tenant SaaS agent, you can’t.

What “doing all three” looks like

A typical production deployment in 2026:

User → Application → Agent loop
                   ↓
                 Function calling (provider API)
                   ↓
               Tool executor (in-process or via Vercel AI SDK)
                   ↓
               OrmAI (policy runtime)
                   ↓
               ORM (Prisma, SQLAlchemy, Drizzle)
                   ↓
               Database

External clients (Claude Desktop, Cursor) → MCP server adapter → OrmAI → ORM → Database

Three layers, three concerns, three independent choices.

Common misalignments

These are the patterns we see most often when teams get the layers wrong.

”We use MCP, so we’re safe”

MCP is a protocol. It doesn’t enforce anything. An MCP server that exposes a SQL query tool is just as unsafe as a function-calling tool that exposes a SQL query function. Same risk, different transport.

”We use function calling instead of raw SQL, so we’re safe”

Better, but only if the functions are policy-aware. Hand-rolled function tools with ad hoc tenant scoping have all the gaps of the hand-rolled tools comparison.

”We have a policy runtime, so we don’t need MCP”

These don’t conflict. Policy runtime + MCP transport = policy-enforced tools available to MCP clients. OrmAI’s MCP adapter is exactly this combination.

”We’ll switch from function calling to MCP later”

You don’t switch from one to the other; you potentially add MCP as a transport. The function-calling interface is between your application and the model provider; MCP is between an external client and your tools. Different relationships.

Decision flow

For a team deciding what to build:

Are you building a SaaS product with an in-app agent? → Function calling + policy runtime. Skip MCP unless you need an external client surface.
Are you building developer tools or shared infrastructure? → All three. The MCP server adapter exposes your policy-enforced tools to any future MCP client.
Are you a single developer prototyping? → Function calling + a thin policy or none. You can add a policy runtime later when you have a real product.
Are you exposing data to external customers’ agents? → All three plus per-customer authentication mapped to capability tokens.

Bottom line

These are three layers of the same stack. Pick the right one for each concern; don’t try to make one layer do another’s job. OrmAI sits at the policy layer; it works with any function-calling provider; it can speak MCP when you want.

Most production stacks end up with all three. Get the policy right first — it’s the layer with the most consequential bugs.