I've now built MCP servers into enough Laravel apps to notice the pattern: I keep rewriting the same tools. Every server needs a whoami. Every server needs to tail logs, peek at failed jobs, retry one, check whether the queue is alive. None of that is domain logic — it's the same generic ops surface, copy-pasted and lightly mutated, in project after project.
So I pulled it into the kit. Today cleaniquecoders/laravel-mcp-kit got a generic, opt-in toolbox — the handful of tools that have zero domain coupling and therefore belong in a package, not in your app. The interesting part isn't the tools themselves. It's the two rules that decide whether a tool even exists in a given install.
The problem with shipping a toolbox
A toolbox package has a tension baked in. You want to ship list_audits, issue_mcp_token, list_roles — genuinely useful tools. But list_audits only makes sense if the host installed owen-it/laravel-auditing. issue_mcp_token needs Sanctum. list_roles needs spatie/laravel-permission.
The naive approach — register them all — blows up the moment the agent calls a tool whose backing package isn't there: a fatal Class not found, or worse, a tool that looks available in the MCP tool list and then errors only when invoked. An agent has no way to know that list_roles is a lie until it's mid-task.
