What we learned connecting a real app to AI through MCP

Most conversations about AI and business software start with the model. Which one is best, which one is cheapest, which one is newest. In practice, the model was the least interesting part of connecting our own product to AI.

The product is Tamoogi, a workspace where Philippine business owners track the permits, filings, tasks, and expenses of every business they run. We gave it an AI assistant inside the app, and an MCP server so people can use it from Claude, ChatGPT, and code editors. These are the lessons that mattered most, and they apply to any team thinking about connecting AI to the systems they already depend on.

Start with the questions people actually ask

It is tempting to expose everything an app can do. A better starting point is what people ask on an ordinary day: What is due this week? What do I still owe? Log this receipt. Remind me before the permit expires.

In Tamoogi, each of those maps to a small, specific tool: list tasks, add an expense, upload a document, create a reminder. Small tools are easier for the AI to choose correctly, easier for people to understand, and easier to limit than one tool that can do anything.

The same idea applies outside software. Before connecting anything, write down the five questions your team asks most often. That list is a better starting point than any feature tour.

Give the AI the same access as the person, and no more

The single most important decision was this: the AI does not get its own access. Every tool runs as the person who signed in, and goes through the same permission checks as the app itself.

That means a collaborator who cannot see a business’s finances cannot see them through the assistant either. Nobody had to write a second set of rules for the AI, which also means there is no second set of rules to drift out of date.

For connecting outside assistants, people sign in with their own account, the same way they would approve any other app. Developers can use a personal key instead. Either way, the AI acts as that person and can be cut off the same way.

Let it read freely. Make changes wait for a person

Looking things up is low risk, so the assistant reads without asking. Changing things is different.

Before the assistant moves money or deletes anything, it stops and shows what it is about to do, and a person presses Confirm. The request is written in plain language (“log a ₱4,800 expense for two fire extinguishers”), so the person approving it does not need to understand anything technical.

This one pattern removes most of the fear people have about AI agents. The assistant still saves time on the routine part, finding the right business, filling in the date, choosing the category, and the judgment stays with the person who is responsible for it.

Do not let the model be the source of truth

AI models are good at language and unreliable with exact facts. Ask one to repeat a list of tasks and it may drop one, merge two, or invent an identifier that looks right.

So when the assistant lists tasks, the app does not trust the model’s version. It takes only the IDs the model points to, looks each one up in the database, and builds the list from the real records. Anything that does not match a real record is dropped quietly. The model chooses which records are relevant. The records themselves say what they contain.

The general rule: let AI decide what to show, and let your system of record decide what is true. This matters most for figures, dates, and anything a person might act on.

Keep sensitive details out of the model’s view

The assistant only needs enough information to answer the question. Before anything it looked up reaches the AI model, card numbers and tax identification numbers are removed, along with anything that looks like a password or access key.

This is a safety net, not a replacement for good access rules. But it means a careless lookup cannot hand a full card number to an outside service.

Expect the model to get the format wrong sometimes

Even with clear instructions, models occasionally answer in a slightly different shape than asked: extra text around the structured answer, a field in the wrong format, technical details that were never meant for the person reading.

An app that shows whatever comes back will eventually show something confusing. Ours checks every reply before it reaches the person, recovers what it can, rewrites replies that leak internal details, and falls back to a simple message when nothing usable remains. None of this is visible when it works, which is the point.

Build once, open several doors

The tools behind the in-app assistant are the same tools behind the MCP server. One set of permissions, one approval rule, one way of protecting sensitive data, and several places people can reach them: inside the app, in Claude or ChatGPT, or from a code editor.

That is the practical promise of MCP for an existing business. You are not adopting a new platform. You are deciding which parts of the system you already run should be reachable by AI, and on what terms.

If you are about to do this

A short checklist, from what we learned:

1. List the questions first. Five real requests from your team are a better spec than a feature list.
2. Reuse your existing permissions. The AI should act as a person, never as an all-access account.
3. Read freely, confirm changes. Anything involving money or deletion waits for a person.
4. Keep facts in your system. Let the model choose records, and show the records themselves.
5. Strip what the model does not need. Remove sensitive details before they leave your system.
6. Plan for imperfect replies. Check what comes back before a person sees it.

None of these steps depends on which AI model you choose. They depend on understanding the work and the system it runs on. That is where we would start with any team, and it is where we started with our own.