Laravel Boost accelerates AI-assisted development by providing the essential context and structure that AI needs to generate high-quality, Laravel-specific code.
Laravel Boost exposes 4 tools via the Laravel MCP framework. All tools are registered with descriptions and input schemas, but several critical issues limit quality: (1) Tool naming lacks action verbs, 'ApplicationInfo', 'DatabaseConnections', 'DatabaseQuery', and 'RecordRule' are noun-based rather than verb_noun patterns like 'get_application_info' or 'execute_database_query'. This violates the 90% baseline for action verb naming and forces LLMs to infer intent. (2) Descriptions exist but are inconsistent in depth and lack guidance on when to use each tool over alternatives. For example, 'DatabaseQuery' says it 'Execute[s] database queries safely' but does not explain the validation rules, destructive operation detection, or recovery paths when validation fails. (3) Input schemas are visible and typed, but parameter descriptions are minimal or absent in several cases. DatabaseQuery accepts 'query' (type string) but the description does not specify format, length limits, or examples of safe vs unsafe queries. (4) Output schemas are not documented, callers cannot predict what fields to expect, breaking tool composition. (5) Error handling is present ('validation against destructive operations') but not guided, no recovery suggestions for agents. (6) The tools operate at different levels of abstraction: ApplicationInfo and DatabaseConnections are read-only discovery tools, while DatabaseQuery and RecordRule are write operations with side effects. This mixing without clear patterns makes it hard for LLMs to compose them safely.
Get comprehensive application information including PHP version, Laravel version, database engine, and all installed packages with their versions. You should use this tool on each new chat, and use the package & version data to write version specific code for the packages that exist.
Get database connection configuration and available connections
Execute database queries safely with validation against destructive operations
Record project rules into .ai/rules directory with frontmatter and entries for tracking decisions and constraints
All tool names are noun-based rather than verb_noun format (ApplicationInfo, DatabaseConnections, DatabaseQuery, RecordRule). Baseline shows 90% of A+ tools start with action verbs (get, list, create, search, update). This forces LLMs to infer intent instead of reading intent from the name.
Output schemas are not documented for any tool. Callers cannot predict what fields to expect, breaking downstream tool composition. Baseline: 100% of A+ tools have documented return types.
DatabaseQuery has no guidance on destructive operation handling or error recovery. Validation is mentioned but the rules, error messages, and retry strategies are not documented. Agents cannot self-correct when queries are rejected.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | 2026-07-28+ | v2 |
Parameter 'title' in RecordRule has no description at all. Baseline: 100% of A+ tool params have descriptions. This leaves the LLM guessing what format or length constraints apply.
Input parameter descriptions lack actionable constraints. E.g., 'query' in DatabaseQuery does not specify forbidden SQL keywords, max query length, or timeout. Baseline: descriptions should include 'expected format, range, and allowed values'.
No pagination or result limits documented for DatabaseQuery. If a SELECT returns thousands of rows, there is no mechanism to limit output or cursor-based fetch. This risks context window exhaustion.
ApplicationInfo and DatabaseConnections descriptions do not explain dependencies or when to use them relative to other tools. E.g., should ApplicationInfo be called first to check PHP version before DatabaseQuery?
RecordRule does not return identifying information (file path, rule ID) in response, breaking tool chains if agent later needs to reference the created rule.