Laravel Boost MCP Server: Full Setup Guide and Hidden Risk

I installed Laravel Boost on a client project the week the “Laravel raised money and now injects ads directly into your agent” thread hit Hacker News, and the timing forced a question most Boost tutorials never ask: what’s actually in the guideline file my agent reads every session, and who can change it after I’ve reviewed it once? Every write-up I found covered composer require laravel/boost --dev and stopped there. None covered the part that matters for a team shipping production code with an agent in the loop: Boost’s guidelines are gitignored by default and auto-update, so the file at the center of the controversy is one most developers running boost:update would never look at twice. This post covers the setup, the real tool list, what the controversy changed, and the one habit that would have made the debate moot for anyone who’d already adopted it.

What Is Laravel Boost and Why Does It Matter for AI-Assisted Laravel Development?

Laravel Boost is an MCP server built by the Laravel team that connects AI coding agents to a running Laravel application so they stop hallucinating routes, models, and package versions that don’t exist in your project. When I first ran it against a five-year-old Laravel 10 codebase carrying a mix of Livewire 2 and 3 components, the difference was immediate — Claude Code stopped suggesting Livewire 3 syntax against components that were still on version 2, because the agent could actually query application-info instead of assuming the latest docs applied.

Boost’s value comes from three things: MCP tools that let an agent introspect the app, a documentation API with over 17,000 pieces of Laravel-specific content searchable by semantic embeddings, and guideline files injected upfront into every session. That third piece — loaded automatically, every time, without re-reading — is what turned a one-sentence PR into a front-page story.

How Do You Install and Set Up Laravel Boost’s MCP Server?

Installation is two commands. Run composer require laravel/boost --dev to pull the package as a dev dependency, then run php artisan boost:install, which detects the packages already in your composer.json and walks you through selecting which coding agents to configure.

composer require laravel/boost --dev
php artisan boost:install

For Claude Code specifically, support is usually automatic, but if the MCP server doesn’t register, you register it manually from the project directory:

claude mcp add -s local -t stdio laravel-boost php artisan boost:mcp

The installer generates a .mcp.json file plus agent-specific guideline files (CLAUDE.md, AGENTS.md, or equivalents depending on the agent you picked). Laravel’s own documentation tells you to add these generated files to .gitignore since boost:install and boost:update regenerate them automatically — a recommendation I’ll come back to, because it’s the exact mechanism the controversy exposed.

What MCP Tools Does Laravel Boost Actually Expose to Your Agent?

Boost’s MCP server ships nine tools in the current release: Application Info, Browser Logs, Database Connections, Database Query, Database Schema, Get Absolute URL, Last Error, Read Log Entries, and Search Docs. Application Info alone returns PHP and Laravel versions, the database engine, every installed ecosystem package with its exact version, and your Eloquent models — which is the single tool that eliminates the most common category of AI-generated code mismatch I’ve hit in production: an agent confidently writing Laravel 12 syntax against a Laravel 10 app.

Database Query and Tinker-style execution deserve a caution most guides skip: a live query tool means a misfired prompt can run against real data. I scope Boost to a dedicated local or staging connection on every project, never the one touching production data.

{
    "mcpServers": {
        "laravel-boost": {
            "command": "php",
            "args": ["artisan", "boost:mcp"]
        }
    }
}

What Happened in the Laravel Boost “Ads in Your Agent” Controversy?

In April 2026, pull request #758 added a deployment section to Boost’s core Laravel guideline — the file injected into every agent’s context on every session. The original draft mentioned several deployment paths, including Nginx, FrankenPHP, and Laravel Forge. Laravel creator Taylor Otwell then trimmed that list down to center Laravel Cloud, the framework’s commercial hosting product, as the recommended option. The PR picked up 54 thumbs-down reactions, and the resulting Hacker News thread, titled “Laravel raised money and now injects ads directly into your agent,” reached 185 points with comments comparing the change to Black Mirror-style corporate influence.

Otwell’s response, posted directly on Reddit, made a demographic argument worth taking seriously rather than dismissing: PHP grew roughly 5% year-over-year on GitHub against JavaScript and TypeScript’s near-90% growth, and a meaningful share of new Laravel adopters have never manually deployed a web app. For that audience, “go configure Nginx yourself” isn’t neutral technical guidance — it’s a wall. The team addressed the specific complaint within about a week via PR #774, which moved the Cloud recommendation into a separate, individually overridable guideline file rather than removing it outright.

I don’t think the controversy proves Laravel is doing anything uniquely wrong — Boost is opt-in, the guideline is a plain .blade.php file you can edit or delete, and Cloud genuinely is the lowest-friction deploy path for a beginner. What the episode proves is structural: any framework vendor shipping an MCP server now has a monetizable surface inside your agent’s context window, and almost nobody was watching that surface for changes until this PR made the front page.

Why Should You Audit Instead of Gitignore Your Boost Guideline Files?

This is the part every “how to install Laravel Boost” tutorial I read skipped, and it’s the actual operational lesson from the controversy. Laravel’s own docs recommend gitignoring the generated guideline and MCP config files because boost:install and boost:update regenerate them. That’s convenient, but it also means a future guideline change — whether it’s a Laravel Cloud recommendation, a shift in testing conventions, or something with real security implications like the encouraged use of $request->all() versus validated input — lands in your agent’s context the next time someone runs boost:update, with no diff, no code review, and no record in your repository’s history.

I treat Boost’s generated guideline files the way I treat a lockfile: committed, diffed on every update, reviewed in the same PR as the dependency bump. It costs one extra step — git add the generated files instead of leaving them gitignored — and it turns an invisible, agent-only behavior change into an ordinary code review comment. Skip this step and you’re trusting every future guideline PR from every package maintainer you’ve installed, sight unseen, indefinitely. Fine for a solo project; not fine for a team shipping client work with an agent in the loop.

What’s New in Laravel Boost v2.4.0’s Security Audit and Best-Practices Skill?

Boost v2.4.0, released March 24, 2026, is a direct response to exactly this class of concern, even though it shipped before the deployment-guideline controversy. The release added a security audit step to the add-skill command, so installing a new third-party skill now surfaces potential issues before it lands in your project. It also introduced a laravel-best-practices skill that checks generated code against 20 rule files covering $fillable/$guarded mass-assignment protection, raw SQL usage, unsafe use of $request->all(), file upload handling, and env() misuse outside config files.

# Skip updates for a specific skill you've customized
php artisan boost:update --ignore=livewire-development

# Pull in guidelines for newly installed packages
php artisan boost:update --discover

The same release removed the Herd MCP integration in favor of the standalone Herd CLI and optimized the core guideline for token efficiency, which matters more than it sounds — every guideline token is context budget an agent isn’t spending on your actual code.

Is Laravel Boost Safe to Use in Production Development Workflows?

Safe, with the same caveats as any tool giving an automated process database access and codebase write access. Scope Boost’s database connection to non-production data, commit and review the generated guideline and skill files, and run the v2.4.0 security audit before accepting third-party skills. None of this is exotic — it’s the dependency hygiene teams already apply to Composer packages, extended to cover the instructions those packages hand your agent.

Comparison: Laravel Boost guideline management strategies

Option	Performance	Complexity	Best For
Default (gitignored, auto-regenerated)	Always current with upstream	Zero setup	Solo projects, quick prototypes
Committed, diffed on update	Current, with a review step	Low — one extra git add	Teams shipping client or production code
Fully custom overrides	Stable, vendor changes don’t apply	Medium — maintain your own guideline files	Regulated industries, strict style guides
No Boost, manual prompting	Depends entirely on prompt quality	None to install, high ongoing effort	Teams avoiding MCP tooling entirely

• Laravel Boost installs via composer require laravel/boost --dev followed by php artisan boost:install, and exposes nine MCP tools including Application Info, Database Query, and Search Docs.
• The April 2026 “ads in your agent” controversy centered on PR #758, which trimmed deployment guidance down to recommend Laravel Cloud; it reached 185 points on Hacker News and was addressed within a week by PR #774.
• Laravel’s default setup gitignores the generated guideline files, which means future vendor changes to those files can alter your agent’s behavior with no diff and no code review unless you commit them yourself.
• Boost v2.4.0 (March 24, 2026) added a security audit to the add-skill command and a 20-rule laravel-best-practices skill covering mass assignment, raw SQL, and unsafe request input handling.
• Scope Boost’s database tools to non-production connections — the Database Query and Tinker tools give an agent live execution access, and a bad prompt can run against real data if you don’t isolate it.
• Overriding any Boost guideline is a matter of creating a matching file path under .ai/guidelines/ in your project — you don’t need to fork the package to change what your agent is told.

Frequently Asked Questions

What is Laravel Boost used for?

Laravel Boost is an official MCP server that connects AI coding agents like Claude Code and Cursor to a running Laravel application, giving them tools to read application info, query the database, inspect routes and logs, and search Laravel-specific documentation so generated code matches your actual installed versions.

Does Laravel Boost slow down my Laravel app?

No. Boost is installed as a dev dependency and its MCP server runs locally alongside your development environment; it doesn’t add any runtime overhead to requests served by your application in production, since the package isn’t installed there at all.

Is Laravel Boost safe to use in production development workflows?

Yes, if you scope its database tools to non-production connections, commit and review the generated guideline files instead of gitignoring them, and run the v2.4.0 security audit on any third-party skills before installing them. Treat it with the same dependency hygiene as any Composer package.

How do I stop Laravel Boost from recommending Laravel Cloud?

Create a file at .ai/guidelines/laravel/core.blade.php in your project to fully override the core guideline, or target a more specific path to override just the deployment section. Boost checks your custom guideline paths first and uses them instead of the built-in defaults on the next boost:install or boost:update.

What’s the difference between Laravel Boost guidelines and skills?

Guidelines load upfront into every agent session and cover broad, foundational conventions. Skills load on-demand only when relevant to the task at hand, covering focused domains like Livewire components or Pest tests, which keeps context usage lower for work that doesn’t touch those areas.

The tutorials already cover the install command. What they don’t cover is that Boost turned your AI agent’s context window into a channel a framework maintainer can push changes through, and the default configuration gitignores the evidence of what changed. That’s not an argument against using Boost — the tool genuinely fixes the version-mismatch problem that makes AI-generated Laravel code unreliable in older codebases. It’s an argument for treating the guideline files it generates as a dependency worth diffing, not a build artifact worth ignoring. Committing them costs one line in your .gitignore and turns the next controversial PR into a code review comment instead of a Hacker News thread. Drop a comment below or subscribe to NexGismo for posts like this delivered weekly.