Office Helper is an internal application we built and use at Appsquire. It tracks what is on the shelves in our supply cupboard and flags items before they run out. It is unglamorous, and it is the kind of small operational system most companies have several of. That made it a good place to answer a real question: what does it actually take to let an AI assistant work with a system you already run?

Recently we found out. Office Helper now connects to AI assistants through the Model Context Protocol, or MCP — a shared format for describing what a system can do. You write the description once, covering what each action is for and whether it changes anything, and any assistant that speaks the protocol can work within it. Ours describes five things Office Helper will do: look up an item, search the shelves, list the categories, report what needs restocking, and change a count. Only the last one alters anything, and it is labelled so an assistant knows to confirm first.

So somebody can ask an assistant what snacks are low and get a real answer from live data, and, with permission, have it update a count. We use Claude, so that is what our screenshots show, but the server does not know which assistant is calling it. ChatGPT, Cursor and GitHub Copilot speak the same protocol and would see the same five capabilities under the same rules. Building to the standard rather than to one vendor is the difference between doing this once and redoing it whenever the office changes tools.

The work that mattered had almost nothing to do with the protocol.

Connecting it was the quick part. Deciding the rules was not.

Wiring an assistant to an existing system is routine work, and it was the shortest phase of this project. Anyone starting one should survey what their existing stack already provides before writing anything; this area moves quickly enough that the answer changes between projects.

The more useful finding was where the time goes. Connection work gets faster with every framework release. The questions underneath do not compress at all: who may act, what they may touch, and what should happen when the assistant is unsure. Those took the bulk of the project, they would take the same again tomorrow, and no library answers them for you.

What should the assistant be allowed to do?

Every request into Office Helper acts as a specific person. Each user creates their own credential and chooses, at that moment, whether it may only look at inventory or also change it. It can be switched off instantly, and we keep no recoverable copy, so a lost credential is replaced rather than recovered.

More usefully, the credential can be narrower than the person holding it. A manager can issue themselves a look-only pass for an assistant they are still getting comfortable with, and that pass cannot change a single number, regardless of what the manager is personally entitled to do. The choice about what an assistant may touch stops being a matter of trust and becomes a setting.

The assistant also cannot claim to be somebody else. An assistant composes the messages it sends, so a system that takes the user's identity from inside those messages has handed its access control to a language model. Ours relies only on the credential presented, and a test deliberately attempts the forgery, sending an administrator's identity inside a request, to confirm the change is still recorded against the credential's real owner.

What should it do when it is unsure?

Tell an assistant we are running out of coffee and Office Helper does not pick one for you. Several things on our shelves answer to that word: two kinds of K-Cup pods and three coffee creamers, all of them currently reading full. It hands back what it found and stops there, so the assistant has to ask which one you meant before anything changes.

This is the decision we are happiest with and the one we see discussed least. An assistant that guesses correctly nine times in ten feels better to use than one that asks. The tenth time is the problem, because a confident wrong answer is silent and nobody goes back to check it. Refusing to guess is not a limitation of the system; it is the feature that makes the other nine answers worth believing.

Every change the assistant makes runs through the same checks a person's would, and lands in the same history of who changed what and when, marked so assistant-driven updates stay distinguishable from ones made by hand. Sixty-four automated tests cover this, and each failure case checks two things: that the request was refused, and that nothing in the data moved.

The questions that outlast the standard

The Model Context Protocol is young and still changing; it has been revised several times since launch. It is tempting to treat keeping current with it as the measure of whether an integration is sound, but it is a poor proxy. When the security firm Censys scanned the public internet for these servers in April 2026, it found 12,520, and reported that the ones it examined were "accessible without authentication."

So the questions worth asking about any integration of this kind are the ones no revision can change. Who is allowed to act? What may they touch? What happens when the system is unsure? Can you reconstruct afterwards who did what? We built Office Helper to answer those four from the first day, and the answers will not change when we adopt a newer version of the standard.

Small systems are the honest test

We can describe this project openly because it is ours and the stakes are snacks. The pattern applies well beyond us. Most organizations already own a system of record with real permissions and a real history of changes, and connecting an AI assistant to it is largely the work of re-expressing a boundary you already have, in a form the assistant reads before it acts, then testing what it refuses to do rather than what it manages to do.

That work is unglamorous, it is where the risk sits, and it is the part a demo never shows you. Contact Appsquire to put experienced engineers on your AI integration before it reaches your production data.