MCP or a Simple Script? A Decision Guide

There is a pattern I now expect in Philippine SME projects. A company decides to automate something, a vendor proposes a connected AI architecture, and eighteen months later nobody can say whether it was worth it.

The technology is rarely the problem. Model Context Protocol works, and for the right situation it is the cleanest option available. The problem is that it gets chosen before anyone has established that the situation calls for it.

This article gives you a way to make that call before you commit budget. Four questions, in order. If you stop early, you save money — that is the point of the sequence.

What MCP Actually Buys You

Strip away the terminology and MCP does one thing: it gives an AI model a standard way to reach your systems, so that adding a sixth system does not mean rewriting how the first five are connected.

That is genuinely valuable — but only when the "sixth system" is a real prospect. If you have one system and no plans for another, you are paying for flexibility you will not use.

Read those honestly. If none of the right-hand column describes you today, MCP is not the wrong technology — it is the wrong stage.

Question 1: How Many Systems Does This Task Touch?

Count them. Not systems your company owns — systems this one task needs to read from or write to.

One system. You do not need MCP. A direct connection or a no-code tool will do it, and will be running next week rather than next quarter.

Two systems. Still probably not. Two connections written directly are simpler to understand and cheaper to maintain than a protocol layer between them.

Three or more, or a number that will grow. Now the argument starts. This is where writing each connection separately begins to cost more than standardising them.

Most Philippine SME automation requests I see are one-system or two-system tasks presented as platform projects. Answer this question first and a good proportion of proposals resolve themselves.

Related: How MCP and Tool Use Help Philippine Businesses Unlock Smarter AI Automation explains this in detail.

Question 2: Does the Task Need Judgement, or Just Steps?

This is the question that decides whether AI belongs in the workflow at all.

Fixed steps, no judgement. "When an invoice arrives, save the attachment, rename it by date, upload it to the shared folder." Nothing here requires a model. A scheduled script or a no-code automation does this more reliably and far more cheaply, and it does not produce a different result on a bad day.

Judgement required. "When a customer message arrives, work out whether it is a complaint, a stock query or a payment issue, and route it accordingly." A model earns its place here, because writing the rules for every phrasing is not practical.

The expensive mistake is putting a model inside a fixed-step workflow. You pay per call, you introduce variability into a process that had none, and you gain nothing. If you can write the rule down completely, do not use AI to apply it.

Question 3: Will More Than One Task Use This Connection?

MCP pays back through reuse. One connection to your inventory system, used by a stock-query bot, a reorder alert, and a monthly report, is three uses of one piece of work.

If a single task will ever use the connection, that reuse never happens, and you have added a layer for no return.

Be strict here. "We might build other things later" is not a second task. Name the second and third tasks, and say which quarter they are planned for. If you cannot, treat this as a one-task connection and build it directly.

Related: How MCP and Tool-Use Help Philippine SMEs Build AI Agents That Connect to Real Business Tools explains this in detail.

Question 4: Who Needs to See What?

The one place MCP earns its keep even for small deployments is permissions.

If the answer to "who can this AI reach, and what may it do there" needs to be different for different people or different tasks, a centralised permission layer is worth having. Payroll data, client records under the Data Privacy Act, supplier pricing — anything where the wrong person seeing the wrong record is a real incident.

For a two-person operation automating its own inbox, this does not apply. For a company with a Philippine back office serving a Japanese parent, where the local team and head office should see different things, it very much does.

Related: What Tool Use and MCP Actually Change explains this in detail.

Reading Your Answers

The middle rows are where money gets wasted, in both directions. Building a platform for one task wastes it upfront. Wiring twelve direct connections because "we will keep it simple" wastes it slowly, over two years of maintenance.

What Each Option Costs to Run

Build cost is the number everyone asks about. Running cost is the number that decides whether the thing survives.

That last row is the real risk in a small organisation. An MCP deployment needs someone whose job includes keeping it alive. If your IT capacity is one person who also handles laptops and the network, factor that in honestly before choosing it.

Common Mistakes

Choosing the architecture before defining the task. If you cannot state the task in one sentence, no architecture decision is meaningful yet.

Counting systems you own rather than systems the task touches. Having eleven systems does not mean this workflow needs eleven connections.

Putting a model in a workflow with no judgement in it. It costs more per run and produces less consistent results than the script it replaced.

Treating "we might expand later" as a current requirement. Build for the task you have. MCP can be introduced later, and migrating two direct connections into it is not difficult.

Ignoring who will maintain it. Ask this before signing, not after the vendor engagement ends.

FAQ

Q: We already built direct integrations. Was that wrong?

A: Not if they work. Direct integrations are the right answer for a small number of connections. Consider moving to MCP when you reach the third or fourth system, or when you find yourself writing the same connection twice for different tasks.

Q: Do we need a developer to run MCP?

A: You need someone who can maintain a running service — update it, restart it, read its logs. That does not have to be a full-time developer, but it cannot be nobody. If you have no such person, start with a no-code tool or a managed service.

Q: Is MCP safe for payroll and client data?

A: The protocol supports proper access control, but safety comes from how you configure it, not from choosing it. Decide what each connection may read and write before it goes live, and keep a log of what was accessed. Under the Data Privacy Act, that log is what you will need if a question is ever raised.

Q: What does a realistic first project look like?

A: One task, two systems, judgement genuinely required — for example routing incoming customer messages by reading them and checking one internal record. Build that, run it for a quarter, then decide about a platform with real evidence in hand.

Q: Will this replace our existing automation tools?

A: Usually not. Fixed-step automations are better served by the tools you already have. MCP is for the parts of a workflow that need judgement across several systems. Most companies end up running both.

Q: How do we stop a vendor overselling us?

A: Ask for the four answers above in writing before any proposal. A vendor who cannot state how many systems the task touches and which second task reuses the connection has not scoped the work yet.

Decide the Task First, the Architecture Second

MCP is a good answer to a specific question: how do I connect an AI model to several systems, for several tasks, with control over what it may reach. If that is your question, it is the cleanest option available today.

If your question is "how do I stop staff copying data between two systems every morning", the answer is smaller, cheaper and available sooner.

Work through the four questions before you talk to anyone about architecture: how many systems, judgement or steps, one task or several, and who needs to see what. Twenty minutes with those questions has saved several of our clients a six-figure peso commitment.

At PH AI Works we scope this with Philippine businesses before proposing anything — including the outcome where the answer is a fifty-line script and no platform at all. If you have a proposal on your desk and want a second view on whether the architecture matches the task, that is a conversation worth having first.

References

No external statistics are cited in this article. The patterns described — platform proposals for one-task problems, models placed inside fixed-step workflows, and MCP deployments left without an owner — come from scoping and delivery work with Philippine SMEs and Japanese-affiliated companies in Metro Manila. Client names and commercial figures are withheld under the relevant agreements rather than estimated, which is why this article gives no price table. Treat the four questions as a scoping tool and obtain your own quotations against the answers.