What is MCP (Model Context Protocol)?

By Dylan Bailey, Certified Claude Expert · Updated 4 August 2026 · 6 min read

Most people meet AI as a chat box. You type something, it types back, and everything it knows about your business is whatever you remembered to paste in. That works, but it puts you in the loop for every piece of context — you become the copy-paste layer between your systems and the assistant.

MCP is the standard that removes that step. It is not something you use directly, and it is not a product you buy. It is an agreement about how AI assistants and business tools talk to each other, and it is quietly the reason some AI tools can do useful work with your real information while others cannot.

The problem MCP solves

Before a shared standard existed, every combination needed its own custom build. If you wanted your AI assistant to read your project management tool, someone had to build that specific integration. Want a different assistant? Build it again. Want a different tool? Build it again. Ten assistants and ten tools meant a hundred separate integrations, most of which never got built.

This is exactly the problem USB solved for hardware. Before it, every peripheral had its own connector. After it, one port worked with everything — not because the devices got smarter, but because everyone agreed on the shape of the plug.

MCP is that agreed shape for AI. A tool implements the standard once, and any AI assistant that speaks MCP can work with it.

What it actually lets an assistant do

An MCP connection gives an assistant three kinds of access:

• Reading things — files, records, documents, calendar entries. The assistant can look at the real thing rather than a summary you typed.
• Doing things — creating a record, sending a draft, updating a row. Actions, not just answers.
• Reusable instructions — saved ways of handling a particular task, so the assistant does it your way rather than its default way.

The practical difference is the gap between "write me an invoice reminder" and "look at which invoices are overdue and draft the reminders". The first needs you to supply the facts. The second needs access.

An Australian small-business example

A Gold Coast trades business runs quoting through a spreadsheet and jobs through a scheduling tool. Without MCP, getting AI help with a quote means opening the spreadsheet, copying the relevant rows, pasting them into a chat, describing the job, and pasting the result back.

With the spreadsheet and scheduler connected, the request becomes: "draft quotes for the three jobs booked next week, using our standard rates". The assistant reads the bookings, reads the rate card, and produces drafts. The owner reviews and sends.

Nothing about the AI got cleverer. It just stopped being blindfolded.

Where to be careful

Access is the whole point of MCP, which means access is also the whole risk. Three things worth holding onto:

• Scope each connection deliberately. An assistant that only needs to read the job calendar should not also be able to delete records. Grant the narrowest access that does the job.
• Know what leaves your systems. Connecting a tool means its data can be sent to the AI provider as part of a request. That may be entirely fine — but it should be a decision, not a surprise.
• Keep a human on anything irreversible. Reading is low-risk. Sending, paying, publishing and deleting are not. Review before those happen.

What this means for you

You don't need to implement MCP, and you probably shouldn't think about it much. What's worth taking away is the question it lets you ask when comparing AI tools: can this thing see our actual work, or does it only see what we paste into it?

That single question separates AI that produces impressive demos from AI that removes real hours from someone's week. The tools that can reach your systems are the ones that end up being used after the novelty wears off.