Writing · 14 Sep 2026

Building MCP servers on top of your Laravel backend

How to expose an existing Laravel or Symfony application to AI agents through the Model Context Protocol — without turning your business logic into prompt text.

Your backend already is the integration layer

Most companies that want "AI with access to our systems" already have the hard part built: a Laravel or Symfony application that knows every business rule, owns the data model and enforces authorisation. The mistake is treating the model as a new system that needs its own copy of that logic. The better move is to expose what you already have — through a Model Context Protocol server — and let the model call into it.

Tools are endpoints with a contract

An MCP tool is, in essence, a function with a name, a description and a typed input schema. That maps naturally onto actions your backend already supports: look up a customer, check an invoice status, create a draft quote. The discipline is in choosing which actions to expose. Expose capabilities, not CRUD. A tool called "draft quote for customer X with these line items" is safe and useful; a tool called "write arbitrary row to table" is neither.

Each tool should validate its input exactly the way your existing form requests or API resources do — because it should literally reuse that validation. If a human user cannot perform the action through your UI, the model should not be able to perform it through a tool.

Identity and authorisation stay in your stack

The most important architectural decision: every tool call carries the identity of the acting user, and your existing authorisation layer decides what happens. Policies, gates and role checks that protect your controllers protect the MCP interface too. This is what separates an enterprise integration from a demo — the model never becomes a backdoor around your permission model, and every action lands in the same audit log as a click in the admin panel.

Keep the protocol at the edge

Treat MCP as a transport concern, not a place where business logic lives. A thin adapter layer translates protocol messages into calls on your application services and translates results back into structured responses. When the protocol evolves — and it will — you change the adapter, not the domain. The same services keep serving your web app, your API consumers and your agents.

What this looks like in practice

Start with two or three read-only tools against real data and one well-scoped write action behind a human approval step. Log every call with inputs, outputs and latency. Watch how the model actually uses the tools for a few weeks — you will find missing context, ambiguous names and error messages that confuse it — then tighten the schemas. An MCP server built this way is not a side project next to your application; it is a new interface on the system you already trust.