We built this in-house to show how the thing works. It was not built for a customer, so there are no business figures anywhere on this page.
The situation
What this kind of business is dealing with
Common in the trade, not a description of anybody in particular. If two or three of these sound like your week, the build below is the shape of the answer.
- People paste spreadsheets into a chat window to get an answer out of them.
- The assistant is useful right up to the point it needs a number from your own system.
- Giving a tool database access is easy, and almost impossible to take back cleanly.
- Nobody can say afterwards what an assistant actually looked at.
- Every new tool wants its own integration, written again from the beginning.
What we built
The pieces of it
Each of these exists and runs. Ask for a walkthrough of any one of them.
- One server, several systems behind it
- A database, an internal REST API and a couple of reporting queries, exposed as a small set of named tools rather than as raw access to anything.
- Read-only by default
- Anything that writes has to be switched on deliberately, one tool at a time. The default answer to "can it change this" is no.
- Permissions scoped per caller
- Each assistant or person gets their own key, and each key gets its own list of tools and its own limits on which rows it can see.
- An audit line for every call
- Who asked, which tool, which arguments, what came back and how long it took. Searchable later, including the calls that were refused.
- Answers shaped for a model, not a screen
- What comes back is small and labelled, so the assistant gets the handful of rows that answer the question instead of a table dump it has to wade through.
- A standard protocol, so it survives the next tool
- It speaks MCP, so any assistant that supports the protocol can use it without another bespoke integration being written.
How it works
What actually happens, in order
- 01
An assistant connects to the server using its own key.
- 02
The server tells it which tools that key may use, and what each one needs.
- 03
The assistant calls a tool -- look up a booking, check a stock level -- with arguments.
- 04
The server checks the key's permissions, runs the query against the real system, and caps what comes back.
- 05
The result goes back as small, labelled data rather than a raw table.
- 06
The call is written to the audit log with its arguments and the size of the result.
- 07
Anything the key is not allowed to do is refused, and the refusal is logged too.
The build
Facts about the thing itself
What it is made of. There are no customer figures on this page, because there is no customer.
Built with
- TypeScript
- MCP
- PostgreSQL
- REST API
- Audit logging