MCP in the enterprise: the business context AI is missing

For a model to call an external tool you need an explicit contract: which resources exist, which parameters they accept and what they return. That is MCP, the Model Context Protocol that Anthropic released as an open standard and that today is declared in `claude_desktop_config.json` or registered directly from Claude Code. The piece AiThority published on 27 August comes at the same problem from the other end: AI adoption inside companies has already happened, and it happened without going through the IT department.

That detail matters more than it looks. When someone in operations pastes a contract excerpt into a chat to get a summary, the model answers with what it knows about the world, not with what it knows about that company. It does not know the product catalogue, the incident history for that client, or the discount policy approved back in March. The text comes out correct and fits badly, which is the worst possible combination inside a working process.

From pasting text to exposing systems

MCP proposes replacing that copy and paste with a declared connection. An MCP server exposes a bounded set of tools and resources: query the CRM, read the current price table, open a ticket, search internal documentation. The model does not receive a whole database, it receives a list of operations it can invoke and nothing else. Whoever builds the server decides what goes on that list, with which permissions and which limits.

That is the data governance part the article highlights, and the part that usually gets buried when the protocol is explained in purely technical terms. An MCP server can be versioned, reviewed in a pull request, restricted by role and logged. A browser tab with an assistant inside offers none of those four things.

Where it fits in the rest of the stack

MCP does not work alone. In Claude Code it lives alongside skills, reusable packages of instructions and context that the model invokes on demand; subagents, meant for delegating bounded tasks; hooks, shell commands that run on lifecycle events such as PreToolUse or PostToolUse; and plugins, which package all of the above for distribution through a marketplace. The division of labour that has worked for us is this:

1. MCP for access to external systems: live data, writes, third party integrations.
2. Skills for stable business knowledge: how a project is named, what format a report takes, what you never promise a client.
3. Hooks for hard rules: validate before writing, block a path, post a warning to a channel.

Mixing those layers up is the most repeated mistake we see in audits. Putting the discount policy inside an MCP server turns it into code someone has to deploy every time it changes; leaving it in a skill keeps it where the person who understands it can edit it, and that person is almost never on the development team.

Who this is useful for

For an IT team that has already lost the battle to ban assistants and needs to redirect it: an internal server with read access over three or four systems does considerably more than a usage policy posted on the intranet. For data owners who need to know what the model queried and when. And for small teams, because the cost of entry is low: a minimal MCP server fits in a few hundred lines and one configuration entry.

It is worth nothing, on the other hand, if the underlying problem is the data itself. A well designed protocol on top of a dirty CRM returns the same as always, only better formatted and with more of an air of authority.

Our reading, after quite a few months building MCP servers for clients, is that the protocol solves the plumbing and solves it well, but the work that actually moves results is the boring one: deciding what each tool exposes and who is allowed to call it. Skip that part and you end up with a better connected assistant giving the same generic answers as before.