What MCP changes for a service business

Most AI features in business software are a text box bolted to a database. You ask a question, something searches, and a paragraph comes back. It is useful for finding things and useless for doing them.

The Model Context Protocol, or MCP, is the plumbing that changes the second half of that sentence. It is an open standard for exposing tools to an AI client: not documents to read, but operations to perform, each with a defined input, a defined output, and whatever permissions you attached to the key.

The practical difference

Without MCP, an assistant that lives inside your field service software can only do what its vendor wired up, in the order the vendor imagined.

With MCP, the same operations are addressable from outside. That means:

• You can use one assistant across several systems. "Look at Thursday's schedule, check the weather at each site, and tell me which roofing visits I should move" involves two tools and no copy-pasting.
• The assistant can chain operations. Finding the gap, checking the crew's certification and booking the visit are three calls, not three conversations.
• You are not locked into the vendor's idea of what an assistant should do.

What it does not mean

It is worth being blunt about the limits, because MCP gets oversold.

It is not a security model on its own. MCP defines how tools are described and called. What those tools are allowed to do is decided by the key you issue and the permissions behind it. An MCP server with an admin key attached is an admin, and it will behave like one when asked nicely.

It does not make the model reliable. A tool call that books a visit will book a visit. If the assistant misread the request, you now have a confidently wrong booking instead of a confidently wrong paragraph. Operations that change money or commit a crew should ask before they act, and the good implementations do.

It is not a migration path. Connecting an assistant to your tools does not clean up your data. If two clients exist twice under slightly different names, the assistant will compound the problem faster than a human would.

How to set it up without regretting it

Issue a scoped key, not your own

Create a dedicated API key for the assistant with the narrowest scope that still lets it be useful. A key that can read the schedule, read clients and draft quotes is dramatically safer than one that can also issue invoices, and in practice it covers most of what you actually want.

Start read-only for a fortnight

Let it answer questions before it takes actions. You will learn quickly where it misunderstands your vocabulary. Most shops have at least one word that means something specific to them and something else to everyone else.

Require confirmation for anything that commits

Booking a crew, sending a quote, issuing an invoice, emailing a customer. These should surface as a proposal you approve, not as a completed action you discover.

Read the audit log

Every tool call should be recorded with who asked, what ran, what changed and when. If your vendor cannot show you that log, the integration is not ready for your business regardless of how well it demos.

A concrete example

Here is the shape of a real request, handled by tools rather than prose:

"Who can take a two-hour callback in Riverside on Thursday?"

  schedule.find_gap(date: 2026-09-17, duration: 120, area: "Riverside")
  crew.availability(date: 2026-09-17, certifications: ["EPA 608"])
  client.lookup(name: "Marla Okonjo")

→ "Crew B finishes at Ridgeway 13:40, eleven minutes away.
   Crew C is booked through Friday. Book Crew B 14:00–16:00?"

Three tool calls, one answer, one confirmation. No dashboard, no filtering, no scrolling a week view on a phone in a van.

Where this ends up

The interesting outcome is not a chatbot. It is that the operational system stops being a place you go and starts being something you can address from a phone, from a terminal, from whatever client you prefer, using the same permissions your staff already have.

That is worth setting up carefully, precisely because it works.