An MCP server over internal systems

The shape of the problem

A team has an internal system with a real API and no AI integration. Staff who want to use an assistant against that data export it and paste it into a chat window, which is both slow and the worst possible answer from a governance point of view.

How the pattern applies

An MCP server exposes a deliberately narrow tool surface over the system: a small number of named, well-described operations rather than a wrapper around the entire API. A smaller surface produces better model behaviour, and it makes the security review tractable.

Read operations and write operations are separated, with writes limited to the specific actions the team agreed to expose.

The permission model

The server acts on behalf of the calling user and inherits that user’s permissions. It does not hold a shared administrative token, because a server built that way silently grants every user administrative reach through the assistant, whatever the underlying access control says.

Every tool call is logged with the calling identity, so access through the assistant is auditable in a way that pasting exports into a chat window never is.

How it would be verified

Against the MCP clients the team actually uses, not against the specification alone. Protocol compliance and working correctly in a given client are not the same property, and the gap between them is where the time goes.