AI assistants are impressive until you ask them something about your own business. An MCP server lets AI work directly, and safely, inside your own software. Here's what MCP is, why it matters, and how we build MCP servers ourselves.
Ask a general-purpose AI assistant to write an email, summarise a report or explain a contract clause, and it does a decent job. Ask it which tickets are still open for your biggest client, how many hours went into a project last month, or whether an order has shipped, and it has nothing to say. Or worse, it makes something up.
That isn't because the model isn't smart enough. It's because it has never seen your data. Your projects, customers, stock levels and invoices live in your own software, and the AI is sitting outside it with no way in.
For the past few years, the usual fix has been a custom integration: write code that connects one specific AI tool to one specific system, then do it again for the next tool and the next system. It works, but it's slow, it's fragile, and it ties you to whichever AI vendor you happened to pick first.
The Model Context Protocol is a different answer to the same problem. And with Laravel now shipping a stable package for it, it has become a practical option for the kind of software we build every day.
What MCP actually is (in plain language)
MCP is an open standard that Anthropic introduced in November 2024 for connecting AI assistants to the systems where data lives. Instead of every AI tool needing its own custom connector to every data source, MCP defines one shared way for the two sides to talk.
The easiest way to think about it is as a universal plug. Your software exposes an MCP server. An AI application, such as Claude, ChatGPT or an AI coding tool, acts as an MCP client and connects to it. Once that connection exists, the model can use what the server offers without anyone writing a bespoke integration for that particular combination.
A concrete example. Say your planning software has an MCP server with a tool that returns open jobs per client. Someone on your team asks their assistant: "What's still open for client X this week?" The assistant sees there's a tool that does exactly that, calls it for the right client, gets the real data back and writes its answer from that. No guessing, no copy-pasting between windows. And tomorrow, the same server works just as well with a different assistant.
An MCP server can offer three kinds of things:
Tools: actions the AI can perform, such as looking up a customer, creating a ticket or logging time.
Resources: data the AI can read for context, such as documentation, records or files.
Prompts: reusable templates that steer the AI towards a specific task.
The important part is that you decide what goes on that list. The AI only sees the tools and data your server chooses to expose, nothing else.
Why it matters for your business
MCP is technical plumbing, but the reasons to care about it are business reasons.
1. Less custom work per integration
Without a standard, connecting AI to your systems means a separate piece of glue code for every tool-and-system pair. With MCP, you build the server once, and any MCP-compatible client can connect to it. That's less code to write, and less code to maintain every time an AI provider changes its API.
2. No lock-in to one AI vendor
The AI landscape changes fast. The model that's best for your use case today may not be next year. Because MCP is an open standard and not tied to a single provider, the work you put into exposing your software isn't thrown away when you switch assistants, or when different people in your team prefer different tools.
3. Control over what's exposed
This is the point we spend most time on with clients. Giving AI access to your business data shouldn't mean giving it access to everything. With MCP, you define exactly which data can be read and which actions can be taken, and you can tie that to the same users, roles and permissions your application already enforces. Read-only where that's enough, write access only where it's genuinely needed.
4. AI that's actually useful
Most AI features disappoint for one reason: they're disconnected from real work. An assistant that can look up the actual order, the actual ticket or the actual customer record is a completely different tool from one that can only guess. MCP is what turns a clever chatbot into something your team can use in day-to-day operations.
MCP and Laravel
We've built custom software on Laravel since 2012, so we've been following the framework's work on MCP closely. In September 2026, the Laravel team released Laravel MCP 1.0, the first stable version of the official laravel/mcp package for building MCP servers inside Laravel applications.
In practice, that means an existing Laravel application can expose an MCP server without bolting on a separate system. A few things stand out to us:
It fits the way Laravel apps are already built. Servers, tools, resources and prompts are regular classes, registered in their own routes file, much like the rest of the application.
Authentication and authorisation are built in. Servers that are reachable over the web can be protected with Laravel Sanctum tokens or OAuth 2.1 via Laravel Passport, and each tool can check what the authenticated user is allowed to do before it acts.
Exposure can be conditional. A tool can be hidden from clients entirely based on the user or the application state, and tools can be marked as read-only so AI clients know they don't change anything.
It's testable. The package includes an MCP Inspector for trying a server out and helpers for writing automated tests, so AI access gets the same quality checks as the rest of the codebase.
For clients with an existing Laravel application, this is the interesting part: making your software AI-ready no longer requires a rebuild. It's an extension of what's already there. Your existing business logic, validation and permissions keep doing their job; MCP is simply another way into the same application.
How we use it ourselves
We don't only recommend MCP, we run on it. Cohively, the workspace we built for our own studio and now offer as a white-labelled product, exposes an MCP server.
It brings our projects, clients, a Jira-style board, time tracking, a password vault and shared docs together in one place. With MCP, anyone on the team can connect an assistant like Claude or ChatGPT and ask for the board, a ticket or an hour in plain words, and the assistant can open or update a ticket just by being asked.
Two design choices matter here, and they're the same ones we'd recommend to any client. Access works through a personal key that each user issues from their own profile, and when issuing it, they choose what that key is allowed to do. Every key carries its own permissions and can be withdrawn on its own. The AI gets exactly the access it needs, and nothing more.
That's also why we're comfortable recommending this approach. The boundaries we suggest for client projects (personal access, scoped permissions, easy to revoke) are the same ones we chose for the workspace our own team depends on, every day, to run the studio.
What this means for you
If your business runs on custom software, MCP opens up a practical question: what would your team do if their AI assistant could safely work with your own data?
A sensible way to approach it:
Start with one high-value use case. A lookup people do dozens of times a day, or an update that's currently retyped between systems.
Expose the minimum. Begin read-only. Add actions only when there's a clear reason, and tie them to existing permissions.
Keep humans where mistakes matter. Let the AI draft, look up and prepare; let people approve what's consequential.
Build on your existing application. If it runs on Laravel, the foundations are already there.
None of this requires betting on a single AI vendor or rebuilding what already works. It's a controlled, incremental step towards AI that knows your business.
Want an MCP server built for your software?
We help you figure out where AI access to your own systems pays off, design an MCP server with the right boundaries, and build it into your existing Laravel application. We always start with a short code audit: we look at your application, map out which data and actions you can safely expose, and tell you honestly which use cases are worth building first.
