MCP servers & LLM integration

Put simply, MCP is a common plug standard for AI applications. Connecting ChatGPT to one system and Claude to another used to mean writing a separate integration for each. With MCP you describe your company systems once, in a standard language, and every AI client that supports the standard can use the same tools. ChatGPT, Claude, Gemini, developer tools and agents you build yourself are all examples of such clients.

An MCP server tells the model: these tools exist, they take these inputs and return this. “Get customer balance”, “list open orders” or “create a draft quote” are each a tool. The model decides which tool to call based on the user’s question; the server checks whether the call is authorised, carries it out and returns the result.

For companies, the real value is that control stays with you. Data is not copied wholesale to the AI provider; only what is needed is shared, only when an authorised call arrives, and every access is recorded.

An MCP server is a thin layer that sits in front of your existing systems. Behind it, it connects to ERPs such as Logo, Mikro, Netsis, SAP Business One or Nebim, to your CRM, to PostgreSQL or SQL Server databases, to document stores in Google Workspace or Microsoft 365, and to your internal APIs. In front, it offers AI clients the standard MCP interface. In most cases your systems themselves do not need to change.

The hard part is not the code but the tool design. Opening a database as it is and saying “run any query you like” is both unsafe and inefficient. Instead we define narrow tools close to business language, each with set return fields, a record limit and accepted filters. We write their descriptions clearly enough for the model to pick the right tool.

We usually write the server in TypeScript or Python and run it on managed infrastructure such as Cloudflare Workers or on your own servers. For data that must stay in-house, a setup running inside your company network is also possible.

Our core principle is that the model can never see or do more than the user can. When a sales rep asks a question through Claude, the MCP server acts under that person’s identity and returns only the customers they can see in the CRM. We build this on OAuth-based authentication and the role structure already in your systems rather than inventing a separate permission world.

We separate read and write scopes strictly. The first release usually ships with read tools only. Write tools, meaning creating or updating records, are enabled under a separate permission; hard-to-reverse actions such as changing amounts or deleting records are either never exposed or require human approval.

Every call is written to an audit log with who, when, which tool and which parameters. Per-user and per-tool rate limits, personal data masking and alerts for unusual usage are a standard part of the setup.

When we add LLM integration to your existing product, we do not bury model calls directly in the code. We put a layer in between: prompts are versioned, the model provider stays swappable, cost is tracked per user and per feature, and fallback behaviour is defined for errors and latency. The layer works the same way with OpenAI, Anthropic and Google models. An MCP server with a handful of read-focused tools can be in use within a few weeks; the schedule grows as write tools and more systems are added.

The most common mistake is exposing every table as its own tool, leaving the model lost among dozens of similar options. The second is granting write access too early. The third is not measuring. A good setup has a test set built from real user questions; whether the model picks the right tool with the right parameters is re-measured after every change, and the audit logs are reviewed regularly.