Laravel MCP is the Model Context Protocol package for Laravel apps

The package that puts MCP inside a Laravel app

Laravel MCP exists so that you can build Model Context Protocol servers for Laravel applications. The package description puts it as rapidly build MCP servers for your Laravel applications, and the mechanism is the Model Context Protocol itself, whose getting started introduction is linked from the README.

The point of MCP servers in this context is that AI clients can interact with your application through them. A client that speaks the protocol can call tools that your application exposes, and the application answers with its own data and its own authorisation rules, rather than the client reaching around the application to a database.

The audience is Laravel developers who already have an application with models, policies and business logic, and who want to expose some of that surface to an AI client without building a second service. The alternative framing is the key: this is not a Laravel application that talks to a model, it is a Laravel application that is talked to by one.

It is an official package from the Laravel organisation, published on Packagist as laravel/mcp, and licensed under the MIT licence.

The README is a signpost, the documentation is the product

The README is short, and that is worth naming rather than hiding. There is an introduction paragraph, then a link to the official documentation on the Laravel website at laravel.com/docs/mcp, then sections for contributing, code of conduct, security vulnerabilities and the licence.

No install command, no code sample and no configuration snippet appear in it. If you are evaluating this package, the repository front page will not tell you how to register a tool, how to describe it to a client, or how to authenticate the connection. All of that has to come from laravel.com/docs/mcp.

That arrangement is normal for a framework vendor package. Laravel ships framework packages with a pointer to the site documentation, and the site documentation is versioned and updated separately from the repository. The practical consequence is that a reader who wants to judge the API has to leave the repository, and a reader who wants to judge the code has to read src/.

For anyone writing about or reviewing this package, the honest summary is that the repository proves the package exists and is maintained, and the site documentation proves what it does.

The directory layout follows Laravel package conventions

The top level of the repository is the usual shape for a Laravel package, and the entries tell you where to look.

src/ holds the implementation, routes/ holds the route definitions for the HTTP layer the package needs, config/ holds publishable configuration, and resources/ holds the views and any frontend assets, including the logo artwork under art/. stubs/ is the directory that holds the skeleton files a package copies into the host application, which is how Laravel packages ship publishable class and config files.

The testing side is visible too. There is a tests/ directory, a testbench.yaml file, and a phpunit.xml.dist configuration. The testbench file is the mechanism Laravel packages use to boot a throwaway application in tests, which is what lets a package test controllers and routes without a real project around it.

Two directories are unusual enough to be worth a mention. There is a workbench/ directory, which in the Laravel ecosystem is a development harness for running the package inside a full application while working on it. And there is an .agents/ directory at the root, which suggests the project carries configuration aimed at coding agents working in the repository.

None of this is exotic, but together it says the package is built to the conventions of the framework rather than as a standalone script.

Static analysis, formatting and refactoring are all configured

The quality tooling is declared in the root of the repository, and it is a fairly complete list for a PHP package.

phpstan.neon.dist is the static analysis configuration, so types are checked rather than left to runtime. phpunit.xml.dist configures the test runner, and testbench.yaml points the tests at the Laravel test harness. pint.json is the configuration for Pint, the code style fixer Laravel uses, which keeps formatting a machine decision instead of a review argument.

rector.php is the interesting one. Rector applies automated refactors, which is how a package prepares its codebase for a new PHP version or a deprecated API without a large hand edit. For a package whose whole purpose is to sit inside applications of many different versions, that kind of maintenance tooling matters more than it would in an application.

composer.json and composer.lock sit alongside those, and there is a CHANGELOG.md and an UPGRADE.md. The presence of an upgrade guide is a sign that the package has already crossed a major version boundary and expects people to be moving between them.

Version 1.0 arrived in the autumn of 2026

The release history is short and recent. Version 1.0.2 was tagged on 2026-10-12, version 1.0.1 on 2026-09-24, and version 0.9.6 also on 2026-09-24, minutes apart according to the timestamps. The 0.9 line and the 1.0 line were therefore developed and released close together.

The repository is not archived and the last push was on 2026-10-19, so work is landing continuously and the 1.0.2 tag is not the end of the story. There is no homepage other than the documentation site, and the package publishes to Packagist with a stable version badge in the README.

Two things follow for an adopter. First, this is a package that reached 1.0 recently, so the API is less settled than the version number might suggest, and the UPGRADE.md file is the place to look when you move between the 0.9 and 1.0 lines. Second, the combination of a fast release cadence and a young major version means pinning is reasonable and reading the changelog before upgrading is not optional.

The MIT licence keeps the legal side simple for most uses, though any specific question about it belongs with your own counsel.

What the repository does not tell you

Since the README carries no code, several questions a new user would normally answer from the front page have to be answered from the site documentation or by reading the source.

Whether the server is exposed over HTTP or over stdio, how a client authenticates, how tools are registered and named, how errors are reported back to the client, and how a tool is scoped to a tenant or a user are all unknown from what the repository shows. The routes/ and config/ directories suggest the HTTP side is there, and the presence of an Eloquent oriented package with a workbench harness suggests a database backed tool surface, but that is an inference from the layout rather than something the documentation states.

There is a related question about safety that the package does not address in the repository: an MCP server exposes application actions to an AI client, and the design of that surface, such as which operations are read only, which require confirmation, and how authorisation is enforced per tool, is where the real design decisions live.

That is not a criticism of the package. It is a reason to read laravel.com/docs/mcp rather than the README before deciding anything.

A Laravel package versus a server you write yourself

There is a real alternative, and it is not another vendor package. You can implement the Model Context Protocol directly in your Laravel application yourself, using the protocol documentation and whatever HTTP or JSON plumbing you already have in the project.

The difference in approach is where the work goes. A hand written server means you define your own tool registration, your own request handling, your own schema for describing tools and your own error mapping, and you maintain all of it. A framework package means those decisions follow patterns the Laravel community already made, and the package handles the plumbing so your code is mostly the application logic.

What you give up by taking the package is control over the protocol surface. If your application needs an unusual transport, a bespoke authentication scheme or a tool description shape that does not fit the package's model, you end up working around the package instead of around the protocol, and at that point the hand written route is cheaper.

For most Laravel teams the deciding factor is not capability but who maintains the wiring when the protocol changes. A package released by the framework organisation is more likely to track protocol revisions than code you write and forget, and the 1.0 line and the ongoing commits are the evidence for that.

Editorial conclusion

Laravel MCP is the sensible choice for a team that already runs Laravel and wants an AI client to talk to their own application, because it is the framework's own package and it follows Laravel conventions rather than asking you to run a separate server alongside the app. It is the wrong tool if you want to read the API from the repository, since the README carries no code and the reference lives on laravel.com/docs/mcp. Before adopting it, read that documentation against your own app, check UPGRADE.md if you are moving from the 0.9 line, and decide whether your tools should act through Eloquent models or through narrower query scoped services.

Frequently asked questions

Official sources

1. Issues
2. laravel/mcp on GitHub
3. License: MIT
4. README
5. Releases