Off-the-shelf AI connector or custom MCP server? How to decide

A year ago, connecting an AI assistant to your business systems almost always meant custom work. Now a lot of the software you already pay for ships its own connector. Many CRMs, helpdesks, project tools and databases offer a ready-made MCP server you can switch on in an afternoon.

That's good news, and it raises a fair question we hear on nearly every discovery call: why would we pay for a custom MCP server if our tools already have one?

Often you shouldn't. Here's how we help clients decide.

Quick refresher: what an MCP server does

Model Context Protocol (MCP) is an open standard for connecting AI assistants like Claude to real systems. An MCP server publishes a list of tools, which are specific actions like "look up an order" or "create a ticket," and the assistant calls them when they help answer a question. You decide which tools exist, what they can read, and what they can change.

If that's new to you, our MCP page covers the basics in plain English.

When the off-the-shelf connector is enough

Use the vendor's connector when most of these are true:

• The work lives in one tool. "Summarize this week's tickets" or "find the deal notes for this account" only needs the helpdesk or the CRM.
• The vendor's actions match how you work. Their tools map cleanly to what your team actually does.
• Their permission model is good enough. The connector respects the same user permissions as the app itself, and that's the access you want the assistant to have.
• You're mostly reading. Looking things up and summarizing are low risk and high value.
• You want to learn before you invest. A ready-made connector is a cheap way to find out which questions your team actually asks.

Turn it on, use it for a few weeks, and watch where people get stuck. That's free discovery for whatever comes next.

When you need a custom MCP server

A custom server earns its cost when:

1. The answer lives across several systems

"Can we ship this customer's order by Friday?" might need the order system, the inventory database and the shipping provider. Vendor connectors each see their own slice. A custom tool can do the joining and return one clear answer, rather than leaving the assistant to stitch three partial ones together.

2. The system is yours

A custom platform, an internal database, or a long-lived application someone built years ago won't have a vendor connector, because there's no vendor. This is the most common reason we build servers. MCP wraps what you already have. You don't have to modernize the system first.

3. You need business actions, not API actions

Vendor connectors tend to expose what the API offers: create a record, update a field. Your team thinks in business actions: "issue a store credit for this order," "flag this account for renewal." A custom tool can carry your rules inside it. It checks the conditions, applies the policy, and refuses what it shouldn't do.

4. You need tighter control than the vendor offers

Maybe support staff should look up orders but never see payment details. Maybe any write needs a confirmation step and an audit record. Maybe certain fields can't leave your environment at all. With a custom server, you define exactly what's exposed and log every call.

5. The connector is too broad

Some connectors expose dozens of actions. More tools isn't better. A long list of vaguely named tools makes the assistant slower and less reliable at picking the right one. A small set of sharp, well-described tools usually beats a big generic one.

A simple way to decide

Answer three questions for the workflow you care about most:

1. How many systems does one good answer need? One points to the vendor connector. Two or more points to custom.
2. Does the action carry business rules? If no, the vendor connector is fine. If yes, go custom.
3. Who must not be able to do this? If the app's existing permissions already cover it, use the vendor connector. If you need finer control or an audit trail, build custom.

Mixed answers are normal. Plenty of teams run both, with vendor connectors for single-tool lookups and a custom server for the cross-system workflows and your own platform.

What a custom server involves

A focused first server covers one system (or one cross-system workflow) and the handful of tools worth the most to your team. The shape we've found works:

• Start read-only. Earn trust with lookups before adding anything that changes data.
• Name tools in business language. "Find order by email" beats "GET /orders."
• Put writes behind confirmation, and log every call.
• Keep credentials in a secrets store your team already trusts. The assistant never touches your database directly.

That's the scope of our MCP Sprint: fixed price, typically two to four weeks, built and handed over to your team. You own the code, and it can run on your infrastructure or ours.

The honest answer

If a ready-made connector does the job, use it. We'll tell you that on the first call. Custom work is for the places where your business is different from everyone else's: your own systems, your own rules, and the questions that cut across tools.

For more on where AI pays off first, see AI for small businesses in 2026: a practical guide. Or tell us which workflow you'd automate first.