MCP Server or Bespoke Integration?
Your team's agent needs to look up customer records in an internal
CRM. A teammate proposes writing a single function — get_customer(id)
— that calls the CRM's REST API directly and returns JSON, wired
straight into your app's function-calling setup. Someone else says
"we should build this as an MCP server instead."
- What questions would you ask before picking a side?
- Walk through how the answers to those questions point you toward MCP or toward the bespoke function.
- Suppose you build the bespoke function today, and six months later a second team wants the same CRM access. What would you do, and is that outcome evidence the original bespoke decision was wrong?
1. Questions to ask first
- Is there, or is there likely to be soon, more than one consumer — another internal agent, another team, a different host application?
- Is this capability something worth distributing outside this one app — to other teams, or eventually to third parties?
- Does the CRM access need to be usable by multiple different host applications (a chat agent and a coding agent, say), or is it intrinsically tied to this one product's workflow?
- What's the operational cost of standing up and running a server process versus adding one function to the existing app?
2. How the answers point the decision
If today there's exactly one consumer, no other team has asked for CRM access, and the lookup is a small, tightly-scoped piece of this one app's workflow, that's a clean bespoke-function case: minimal overhead, no interoperability need to pay for. If instead the request is coming from a platform or integrations team building this on behalf of multiple internal agents, or another team has already asked for the same access, that reuse signal points toward an MCP server — built once, discovered and used by every consumer without a repeat integration. The deciding factor is reuse and distribution, not the complexity of the CRM API itself — a simple API with three consumers is a better MCP candidate than a complex API with one.
3. Six months later, a second team wants the same access
At that point, the right move is usually to extract the bespoke function into an MCP server: wrap the same underlying CRM logic behind a server, let the original app and the new team's agent both connect to it, and retire the duplicated bespoke call in the original app once the migration is verified. This is not evidence the original decision was wrong — at the time, there was one consumer and no reuse signal, so bespoke was the lower-overhead choice with the information available. A design is not wrong because circumstances changed later; it would only be wrong if the reuse signal was already visible and ignored. Treat "graduate to MCP when a second consumer shows up" as the normal lifecycle, not a correction of a mistake.
Share this question