Claude MCP vs custom tool APIs: which fits your agent project

Anthropic's Model Context Protocol (MCP) gives Claude a standard way to reach external systems. For teams building agents on Claude, that raises a real evaluation question: do you connect your platform to Claude through MCP, or do you build and host custom tool APIs that Claude calls directly?

This comparison is for engineering and product leaders at SaaS companies who already have a Claude agent project in flight and need to decide how that agent will reach their own product. We'll skip the protocol primer and focus on the trade-offs that determine which approach holds up in production.

Short version: Claude MCP wins when you want a reusable server that any MCP-aware client can talk to, and you're comfortable owning a long-lived protocol surface. Custom tool APIs win when you need tight control over a single agent's behaviour, your tools are narrow, and you don't need cross-client portability. Most production teams end up needing both at different layers.

How Claude MCP works

MCP is an open protocol Anthropic introduced in late 2024. It defines a client-server contract: an MCP server exposes tools, resources, and prompts; an MCP client (Claude Desktop, the Claude API with MCP support, or any other compliant runtime) discovers and invokes them over a standard transport. The server is yours to build and host. The protocol handles capability discovery, tool schemas, and message framing.

For a Claude MCP integration, the practical flow is: you stand up an MCP server in front of your platform's APIs, define each tool's input schema and behaviour, deploy the server somewhere Claude can reach it, and configure the Claude client to connect. Claude then sees your tools as first-class capabilities it can plan against. Because MCP is a protocol rather than a Claude-specific SDK, the same server can serve other MCP-aware agents — Cursor, Windsurf, and a growing list of clients — without rewriting the integration.

How custom Claude tools work

Claude's tool use feature predates MCP. You define tool schemas inline in your API request to Claude, Claude returns a structured tool call, your code executes it against your backend, and you return the result in the next turn. The tools live wherever your application code lives. There's no separate server, no protocol to implement, no transport to configure.

This is the path most teams started on, and it's still the right path for many. You get full control over which tools Claude sees on which turn, you can shape descriptions per-conversation, and you can keep tool execution inside the same process as the rest of your agent logic. The cost is that the tools are bound to one client (Claude, via your application), and every new agent project that needs the same capabilities re-implements them.

Comparison

When to choose Claude MCP

Choose MCP when reuse is the point. If you have multiple agent projects that all need to reach the same product capabilities — a Claude agent for customer support, a Cursor integration for engineers, an internal Claude Desktop setup for ops — building one MCP server beats building three bespoke tool layers. The protocol earns its keep when the same tools serve more than one caller.

It also makes sense when your tools are stable and well-bounded. MCP rewards tools that change rarely and behave predictably. If your platform exposes a clean set of operations that you'd happily document as a public interface, an MCP server is a good shape for them.

Finally, choose MCP when you want the option to expose your tools to clients you don't control. The protocol is open. A customer running their own Claude setup can point it at your MCP server the same way Claude Desktop does. That's a real distribution channel for SaaS products whose users want to bring their own agent.

When to choose custom Claude tools

Choose custom tools when you're early, the agent is one product, and the tool surface is changing weekly. Inline tool definitions let you iterate without protocol overhead. You can add a tool, ship it, and remove it the next day without versioning a server.

Choose them when per-turn control matters. If your agent's behaviour depends on advertising different tools at different stages of a conversation — different tools during onboarding than during a checkout flow, say — inline definitions handle that naturally. MCP servers tend to advertise a stable catalogue.

And choose them when your tools are tightly coupled to application state that already lives in your backend. Wrapping that in an MCP server means re-exposing the state across a protocol boundary you didn't need. Keeping the tools inline keeps the architecture honest.

The harder problem underneath both

The MCP-vs-custom-tools question is real, but it's downstream of a bigger one: where do the tools come from in the first place?

Both approaches assume you already have APIs that cover the capabilities your agent needs. For most established SaaS companies, that assumption breaks. Products were built for the UI. The APIs covered some of it; the rest stayed locked behind UI-only flows. So whether you wrap those APIs in an MCP server or call them inline as Claude tools, you're exposing the same partial surface — and the agent hits the same ceiling either way.

We wrote about that gap in your APIs expose 2% of what your product can do. The protocol you choose for the last mile matters less than whether the tools exist at all.

What we'd choose

For a single Claude agent serving one product use case, with a small and changing tool set, start with custom Claude tools. The setup tax of MCP isn't worth it until you have a second caller.

For a portfolio with multiple agent projects across multiple products, or any plan to let customers bring their own agent, build an MCP server. The reuse compounds, and the protocol's openness becomes a feature rather than overhead.

For most teams we talk to, the honest answer is: pick whichever is faster to ship today, and put the engineering effort into the upstream problem — making sure the tools your agent needs actually exist. A great MCP server over a 2% API surface is still a 2% agent. For more on that decision shape, see API modernisation for agents: build, buy, or wait.

How Pontil fits

The MCP-vs-custom-tools choice is a transport decision. The harder decision is what to put behind it. Pontil is a Tools-as-a-Service platform: we generate tools from the APIs and codebases our customers already have, run them as managed tool runtimes, and keep them current as the underlying products change. The output works as MCP tools, as Claude tools, or as tools for any other agent runtime — protocol-agnostic by design.

So if you're picking between MCP and custom Claude tools, pick on the merits above. If you're picking between either of those and not having the tools at all because your APIs don't cover the surface — that's the conversation we have with most teams. You can see how it works when that's where you've landed.