MCP in Practice: When a Model Context Protocol Server Pays Off

Eighteen months after the Model Context Protocol shipped, the ecosystem has settled. Some servers run in production, others were quietly retired. What remains is a question that resurfaces in every roadmap discussion about AI tooling: do we need one of our own?

What MCP Actually Does

The Model Context Protocol is a contract between agent and tool. Instead of every agent (Claude Code, Cursor, OpenCode, custom implementations) bringing its own tool-calling style and schema, they all speak the same language: standardized tool definitions, resource URIs, prompts. A server written once is usable by any compatible agent.

That is not a revolutionary idea - it is a well-written adapter. The value sits in reuse.

Three Criteria for Your Own MCP Server

Our last projects yielded three conditions under which a dedicated server pays off:

At least two consumers. If only one workflow uses the tool, a script is cheaper. The second agent (or human in another IDE) pays back the MCP investment.
Stable tool surface. A function whose signature changes every month does not fit a protocol with a versioned contract. MCP rewards clear, not-too-fine-grained tools.
Compliance or logging requirement. Once access has to be traceable or policy-checked, a central server is the better place than scattered plugins. An OPA layer or audit log gets implemented properly once.

Three Counter-Indicators

It is just as clear when a dedicated server becomes overengineering:

One-off migration or ETL job. A script run three times and then archived does not warrant maintaining a protocol schema.
A dedicated UI already exists. If humans drive the tool primarily through a web UI, the extra MCP surface becomes a second front to maintain.
Only one data source, only one agent. A function call inside an agent skill is enough - the complexity of a dedicated server does not pay back.

For a recent client, customer data lived in an ERP database, contracts in a DMS, availabilities in a calendar. Three sources, six agent workflows, three people working with their own tooling each. A central MCP server hitting the three sources, secured via OPA, was clearly cheaper than six individual integrations.

For another client, the case was a single document classifier for inbound mail. A plain Python script with a cron job did the job in a week - MCP would have added nothing.

The Simple Rule of Thumb

Only when the second "it would be nice if another agent could use this too" lands on the table does the leap pay off. Before that, MCP is a solution still looking for its problem.

What MCP Actually Does

That is not a revolutionary idea - it is a well-written adapter. The value sits in reuse.

Three Criteria for Your Own MCP Server

Our last projects yielded three conditions under which a dedicated server pays off:

At least two consumers. If only one workflow uses the tool, a script is cheaper. The second agent (or human in another IDE) pays back the MCP investment.

Stable tool surface. A function whose signature changes every month does not fit a protocol with a versioned contract. MCP rewards clear, not-too-fine-grained tools.

Compliance or logging requirement. Once access has to be traceable or policy-checked, a central server is the better place than scattered plugins. An OPA layer or audit log gets implemented properly once.

Three Counter-Indicators

It is just as clear when a dedicated server becomes overengineering:

One-off migration or ETL job. A script run three times and then archived does not warrant maintaining a protocol schema.

A dedicated UI already exists. If humans drive the tool primarily through a web UI, the extra MCP surface becomes a second front to maintain.

Only one data source, only one agent. A function call inside an agent skill is enough - the complexity of a dedicated server does not pay back.

Field Example: When We Recommend MCP

For another client, the case was a single document classifier for inbound mail. A plain Python script with a cron job did the job in a week - MCP would have added nothing.