Why I put an MCP server in front of an API instead of giving the model the database

Customers ask for an AI assistant on their data. The safe way to say yes is a small gateway with named tools, the user's own rights and a log of every call.

The request usually arrives as "can we have ChatGPT on our data". Behind it is a reasonable wish: ask a question in plain language and get an answer from the real system. The quick way is to hand a model a database connection and a prompt. I do not do that, and here is the shape I build instead.

Named tools, not raw access

MCP, the Model Context Protocol, is the open standard assistants use to call tools. An MCP server in front of your existing API exposes a short list of named tools: orders.search, customer.get, stock.low. Each tool does one thing, validates its input, and calls the API the way the app already does. The model never sees a table.

The user's own rights

The gateway runs every call with the token of the person asking. Someone who cannot see another customer's orders in the app cannot see them through the assistant either. No separate permission model to keep in sync.

Read first, write with a human

Read tools ship first. Write tools exist only where a person approves the action, and the approval is part of the tool, not a promise in a prompt.

Every call logged

Who asked, which tool ran, what came back. The log is what makes the thing auditable and what shows, after a month, which questions people actually ask.

The part that pays

The API did not change. A new assistant, or a new model, is a configuration change. I built this pattern for my own inventory product and it is the one I sell as AI Integration; the case study is on this site.

More notes: PHP 8.4.27, 8.3.36 and 8.5.12: what the 21 October security release means for you · What two days of Health Check buy you · all posts