MCP for Knowledge Workers: How AI Gets Access to the Software You Use

For most knowledge workers, AI started as something you talked to.

You opened ChatGPT or Claude, asked a question, and received an answer. It could help you write a report, analyse an argument or structure a presentation. But when the answer involved another application, there was usually a boundary: you still had to open that application and do the work yourself.

That boundary is beginning to move.

AI can increasingly work with the software, files and systems around it. MCP, or Model Context Protocol, is one of the technologies making that possible.

The name sounds technical. The underlying idea is much simpler.

Model = the brain
Harness = everything we build around the brain so it can actually work
MCP = one standardized way the harness connects that brain to external tools and systems

A model might be GPT-5.6 Sol or a Claude Opus model. ChatGPT and Claude Desktop are applications through which we interact with models.

The harness is the working environment around the model. It can provide the instructions, information, memory, tools, permissions and checks the model needs to do useful work.

MCP is one part of that harness. It is not another AI model, and it is not the whole system around the model. It is a standard way of connecting the AI to things outside itself.

Before looking more closely at MCP, however, it helps to understand the different ways AI can work with the applications we already use.

Three ways AI can work with software

Imagine that you are preparing a quarterly business review. Some information is in Excel, customer information sits in a CRM, and the final presentation will be prepared in PowerPoint.

AI can enter that workflow in several ways.

The first is AI built into the application. Microsoft can provide AI features inside Excel or PowerPoint. Notion can provide AI inside Notion. Salesforce can provide AI functions within its own software.

The second is an external AI connected to the application. You might work in Claude, for example, and allow it to use selected capabilities from another application. MCP is one way of creating that connection.

The third is computer use. Instead of receiving a structured connection to the application, the AI sees and operates the interface much as a person would: clicking buttons, entering information and moving through screens.

Each approach has different strengths.

Approach	How to think about it	Main advantage	Main limitation	Best suited to
AI built into the application	The brain is already inside the tool	Usually the simplest experience because the AI and application are already integrated	You depend on the capabilities the software provider chooses to offer, and the AI may have limited reach outside that application	Work that stays mainly inside Excel, PowerPoint, Notion, Salesforce or another single system
External AI through MCP	The brain is outside the tool but has a controlled connection into it	An AI you choose can potentially work across several applications and use selected capabilities from each	The application must expose suitable capabilities, and access has to be controlled carefully	Work that needs reasoning across one or several systems
Computer use	The AI operates the software as a person would	It can work with applications even when no structured AI connection exists	Screens, buttons and menus can change, making it generally more fragile than structured access	Software that does not offer suitable MCP or other machine-facing access

None of these is automatically better.

If the work stays inside one application, its built-in AI may be the easiest choice. MCP becomes more interesting when an external AI needs to work across systems. Computer use becomes useful when the only practical route is through the same interface a person would use.

This distinction will become important later.

But first, it helps to look at how software worked together before AI entered the picture.

Before MCP, software already talked to software

Connecting business applications is not new.

For years, companies have used automation platforms such as Zapier, Make, Microsoft Power Automate and n8n to make one application respond to something that happens in another.

A workflow might look like this:

New sales lead arrives → create a CRM record → notify the sales team → create a follow-up task.

These platforms did not usually create the underlying connections from scratch. Applications such as Salesforce, Gmail or Slack typically provided their own APIs.

An API, or application programming interface, is a structured doorway through which one piece of software can ask another for information or request an action.

Salesforce might provide a way to say, in effect:

“Create this customer record.”

Gmail might provide another:

“Send this email.”

Zapier, Make and n8n made these APIs much easier for ordinary users to work with. They built connectors, visual workflow builders and reusable templates on top of them, so a user could connect applications without writing all the integration code personally.

Traditional automation then linked those capabilities into a predetermined sequence:

Trigger → API call → API call → result

This is still an excellent way to automate work when the process is known in advance.

Then AI became part of the workflow

As generative AI became more widely used, people started inserting AI into these automated processes.

A customer email could arrive, for example, and the workflow might send it to an AI model to determine what the customer wants:

New email arrives → AI classifies the request → automation routes it to the correct team → CRM is updated.

The AI provides judgement at one point, but the overall workflow has still been designed beforehand. Someone has decided which step comes first, where the AI is used and what happens after it responds.

That is different from giving an AI several tools and asking it to work towards a goal.

Suppose instead that you say:

“Review this customer's situation and work out what needs to happen next.”

An AI with appropriate tool access might inspect the CRM, retrieve an earlier document, check the status of a project and then decide which action is appropriate.

The sequence does not necessarily have to be designed in advance.

This gives us a useful distinction:

AI inside traditional automation
Fixed workflow → AI performs a reasoning step → fixed workflow continues

AI agent with access to tools
Goal → AI reasons → chooses appropriate tools → acts → checks the result

Here, agent simply means an AI operating in an environment where it can use tools and take steps towards an objective rather than only return an answer.

The distinction is becoming less tidy because automation platforms such as Zapier, Make and n8n are themselves adding increasingly agent-like capabilities.

So the useful question is not:

“Am I using Zapier or MCP?”

It is:

Did I design the sequence beforehand, or did I give the AI a goal and tools and allow it to decide how to pursue that goal?

This is where MCP starts to matter.

What MCP changes

Without access to another system, the relationship between you and AI often looks like this:

You → AI → instructions back to you → you operate the application

The AI may understand the problem perfectly. But you remain the person translating its advice into application commands.

With MCP, the flow can become:

You → AI → MCP → application → result

MCP does not perform the business operation itself. The application still does that.

What MCP provides is a standard way for an AI to discover and use capabilities that another system has chosen to make available.

If an application exposes a function for finding a customer record, creating a project or exporting a document, the AI may be able to use that function directly instead of telling you which menus and buttons to use.

For a knowledge worker, this is the important definition:

MCP is a standard way for an external AI to use selected capabilities and information from another application or system.

MCP also does not replace APIs. An MCP server may use an application's existing APIs underneath.

A simple way of remembering the relationship is:

API = a structured doorway into an application's capabilities
MCP = a standard way for AI to discover and use capabilities made available to it as tools

You do not need to understand the technical plumbing behind either one to make use of the distinction.

What “external AI through MCP” actually means

There are a few formal terms worth recognising because you may encounter them when connecting software or talking to an IT team.

Suppose you are using Claude Desktop.

Claude Desktop is the MCP host: the environment in which you are working with the AI.

Inside the host, an MCP client manages the connection.

At the other end, an MCP server exposes selected capabilities or information from the system you want the AI to use.

In simplified form:

You → MCP host → MCP client → MCP server → application

You do not need to remember that chain every time you use MCP.

For everyday purposes, I find external AI through MCP a more useful description.

The important point is that the AI remains outside the other application. It gets controlled access through the connection that has been provided.

Why permissions matter

Once an AI can reach another system, an obvious question appears:

What should it be allowed to do?

This is why MCP connections involve permissions.

A useful mental model is an office access badge.

Signing in proves who you are. In technical language, that is authentication.

The badge then determines which doors you are allowed to open and what you can do once you are inside. That is authorization, or permission.

An AI connection works on a similar principle.

It may be allowed to inspect records without changing them. It might be able to create a draft but not publish it. Perhaps it can prepare an email while requiring you to approve the final send.

The application provider also decides which capabilities are available in the first place.

A CRM might allow an AI to search customer records and create notes but not delete accounts. Another application might expose extensive editing functions.

So seeing that an application “supports MCP” does not mean the AI receives unrestricted control.

Two separate questions matter:

What has the application made available?

and:

Which of those capabilities have I allowed the AI to use?

Common tool names become easier to understand once translated into ordinary language. Get usually means “show me this particular thing.” List means “show me what exists.” Create makes something new, while update, delete, send or publish involve increasingly consequential changes.

The exact meaning depends on the application, so the name alone should never be treated as a guarantee.

The practical principle is simpler:

Give the AI the authority it needs for the task in front of it, rather than every authority it might possibly use later.

A sensible way to start using MCP

If you connect AI to a new system, there is little reason to begin with a large or irreversible task.

First find out what the connection exposes.

Let the AI inspect information before allowing it to make changes. Then give it a small job whose result you can easily verify.

Imagine a project system containing hundreds of active projects.

Instead of beginning with:

“Reorganise our entire project database.”

you might ask:

“Find five projects due this month that are marked at risk and explain what you found.”

If the result is correct, the next step could be:

“Create a draft follow-up task for one of them.”

You are gradually increasing both the complexity of the work and the authority given to the AI.

This is similar to how we introduce a new person into an important business process. We give them enough access to do the current job, observe the result and expand responsibility when there is good reason to do so.

A simple way to think about the levels of authority is:

Read — inspect or retrieve information.
Create — make something new.
Modify — change something that already exists.
Act externally — send, publish, purchase, deploy or trigger another consequential process.

These can all be legitimate uses of MCP.

They should not all be treated as carrying the same risk.

MCP or something else?

Now we can return to the three approaches we started with.

If you only need the AI to think, explain, draft or analyse material that is already available to it, ordinary AI chat may be sufficient.

If an application already provides capable built-in AI, that may be the simplest way to work within that application.

When an external AI needs structured access to information or capabilities in another system, MCP becomes relevant.

If structured access is unavailable, computer use provides another route. The AI works through the visual interface: reading the screen, clicking controls and entering information much as a person would.

And some tasks do not need AI at all.

Consider:

Every Friday at 5 p.m., copy the same five figures from system A into system B.

The process is fixed. Conventional automation can handle it reliably.

Compare that with:

Review the regional performance reports, identify which business units need management attention, explain why, and update the planning system with the relevant actions.

Now judgement is part of the job. An AI that can reason and use the appropriate tools becomes much more interesting.

A useful starting rule is therefore:

If the process is fixed, automate it. If the process requires judgement, AI with tool access may be more useful.

It is not an absolute rule. Real business processes often contain both.

A future workflow may use traditional automation for predictable steps, AI for judgement, MCP for structured tool access and computer use where no better interface exists.

Understanding the pieces helps you decide where each belongs.

Why this matters beyond MCP

At this point, we can return to the harness.

The model provides the reasoning ability, but useful work depends on what surrounds it: the information it can see, the instructions it follows, the tools it can reach, the permissions it receives and the checks placed around its work.

That environment determines both what the AI can do and what it should be allowed to do.

MCP is one component of that environment.

This is why harness engineering is not simply about giving AI more capability. It is also about designing boundaries.

The most capable model in the world cannot update your customer system if it has no way to reach it.

Give the same model unrestricted access to everything, however, and you may create a very different problem.

The objective is not maximum access.

It is appropriate access for the work being done.

What remains the human's job?

As AI becomes able to execute more work, the human role changes.

We increasingly decide what outcome we want, what information the AI should use, which systems it may access, what it can do without asking and where approval is required.

We also remain responsible for judging the result.

That gives us one final mental model:

Human intention → AI reasoning → tools and execution → human judgement

MCP can shorten the distance between what we ask an AI to achieve and the software operations required to achieve it.

But the human still sets the objective, defines the boundaries and decides whether the result is acceptable.

That is why MCP matters to knowledge workers.

It is not important because everyone needs to understand a new technical protocol.

It matters because it is part of a larger change in our relationship with software.

The model is becoming more than something we ask for advice. With the right harness, it can increasingly use the tools around us.

The practical question is no longer only:

What can the AI tell me?

It is also:

What should I allow the AI to do?