Laravel Boost 2.6 improves MCP safety and testing guidanceLaravel Boost 2.6 improves MCP safety and testing guidance

Keyword filtering was never enough

When an AI agent queries a database through MCP, blocking words such as UPDATE and DELETE is not a complete safety model. SQL has dialect-specific syntax, edge cases, and statement shapes that are difficult to cover with text-based checks alone. Laravel Boost 2.6.0 keeps the initial validation, but no longer relies on it as the final line of defense.

The key change is in the DatabaseQuery tool. Queries now run inside a transaction that the database engine is asked to enforce as read-only. Boost always rolls that transaction back once the query has finished, including when an error occurs.

That is a more useful trust boundary. An agent can build an unexpected query, or use a SQL form that slips past a lexical filter, and the database still has a chance to reject a write. This is enforcement by the database engine, not just a rule written for the model.

The implementation follows the database driver

Boost uses a different approach for each supported connection type. On MySQL and MariaDB, it marks the transaction as read-only before opening it. PostgreSQL receives the read-only setting after the transaction starts, while SQLite uses PRAGMA query_only.

That distinction is not cosmetic because transaction behavior differs between engines. The implementation checks Laravel's current connection driver and runs the relevant statement before performing the query. There is no new config/boost.php switch to enable; the behavior comes with the package update.

After updating dependencies, the official documentation recommends refreshing Boost's generated resources with these commands:

composer update laravel/boost
php artisan boost:update

If the project has newly installed packages and you want Boost to look for additional resources, use --discover. I would not run that blindly in a shared repository, since generated files still deserve a review. Agent configuration is development infrastructure, and it should be treated accordingly.

php artisan boost:update --discover

One testing skill instead of overlapping advice

The other meaningful addition is the testing-best-practices skill. Boost previously had separate, partly overlapping guidance for Pest, PHPUnit, and related testing decisions. That made the result more dependent on which agent was working on the task and which instructions happened to be loaded.

The new skill is not an excuse to add more tests for every small edit. It focuses on observable behavior and application contracts, asks agents to cover changed decisions and valuable failure cases, and discourages tests that only prove framework behavior. It also suggests feature tests first when Laravel is involved, leaving unit tests for logic that does not need the framework.

I find its emphasis on existing repository conventions particularly useful. A project may use Pest with it() or test(), follow a specific authentication setup, or build factories in a consistent way. The agent is expected to inspect nearby tests before applying generic preferences.

The skill adapts to whether the project uses Pest or PHPUnit. It accounts for browser testing when the Pest browser plugin is installed, but it does not push the agent to add packages on its own when that tooling is absent. That is the right constraint: assistance should respect the installed stack instead of expanding it without a clear request.

The fine print matters

A read-only transaction around DatabaseQuery does not make the entire MCP server harmless. It protects database access through that specific tool, not the permissions attached to the database user or any other path a process might have to change data. Development and staging credentials should still follow least-privilege principles.

It also does not solve data exposure by itself. If MCP is connected to a database holding sensitive records, a read query can still reveal information that should not leave that environment. Read-only access is not the same thing as risk-free access.

The testing skill can make an agent's output more consistent, but it cannot automatically understand the business value of every scenario. Some duplicate tests should be reduced, while some missing coverage needs to be added, and both calls still require team context. I would use the skill as a shared baseline and keep application-specific conventions in project rules.

A small release with practical consequences

Boost 2.6.0 does not introduce a new application API or require teams to rewrite existing tests. Instead, it improves two areas where coding agents tend to be unreliable: exploratory database access and inconsistent or excessive test generation. Both changes reduce avoidable mistakes without forcing a different daily workflow.

If you use Claude Code, Codex, or another MCP client with Boost, this update is particularly relevant when agents query the database. I would update the package, run php artisan boost:update, inspect the generated files, and then try it on a real testing task. That is a better validation than assuming generic AI guidance matches the conventions already present in the repository.

• Source: Laravel News
• Official documentation: Laravel Boost v2.6.0