Loading ToolBench
An MCP server to give Cursor, Aider, etc. the ability to introspect your Laravel codebase directly, by querying for your models, views, routes and classes without raw file search.
Laravel Codebase MCP provides 4 specialized read-only query tools with comprehensive, well-structured parameter schemas. All tools are properly named with verb-noun convention (query_*), have detailed descriptions (380-450 chars each), and extensive input schemas with type definitions and parameter descriptions. However, output schemas are not documented in source, error handling guidance is absent, and tool annotations are missing. The tool composition follows single-responsibility principle, each tool queries one Laravel artifact type (routes, models, classes, views). Parameter naming is consistent with underscores separating filter types and matching logic (_or, _and, _or, _and, _and). Wildcard and exact-match behavior is clearly documented per filter category. All tools are READ_ONLY, reducing security surface. Main gaps: no visible output schema documentation, no error recovery guidance, no tool annotations (readOnlyHint), and STDIO transport blocks remote accessibility.
Query the classes in the codebase by applying various filters based on their fully qualified names, implemented interfaces, extended classes, or used traits. If no filters are provided, all classes will be returned. For most filter categories, you can provide multiple values using `_or` parameters. These values are checked with OR logic, meaning a class will match if it satisfies any of the conditions within that specific parameter (e.g., `name_equals_or: ['UserController', 'PostController']` will match classes named "UserController" OR "PostController"). Filters applied via `_and` parameters require all provided values to be present (e.g., `implements_interfaces_and: ['\Illuminate\Contracts\Queue\ShouldQueue', '\Illuminate\Contracts\Support\Renderable']` will match classes that implement both `ShouldQueue` AND `Renderable` interfaces). All distinct filter parameters (e.g., `name_equals_or` and `implements_interfaces_or`) are checked with AND logic, meaning a class must satisfy conditions from all provided filter categories. Wildcards (`*`) are supported for all filters, matching against the fully qualified class name, interface name, trait name or extended class name.
Query the models in the codebase by applying various filters based on their names, properties, relations, implemented interfaces, or used traits. If no filters are provided, all models will be returned. For most filter categories, you can provide multiple values using `_or` parameters. These values are checked with OR logic, meaning a model will match if it satisfies any of the conditions within that specific parameter (e.g., `name_equals_or: ['User', 'Post']` will match models named "User" OR "Post"). Filters applied via `_and` parameters require all provided values to be present (e.g., `has_properties_and: ['name', 'email']` will match models that have both 'name' AND 'email' properties). All distinct filter parameters (e.g., `name_equals_or` and `has_properties_or`) are checked with AND logic, meaning a model must satisfy conditions from all provided filter categories. Wildcards (`*`) are only supported for model name and class/interface/trait filters. For property and relation filters exact matching is required.
Output schemas not documented. Tool descriptions explain filtering behavior but do not specify what fields and types are returned. LLMs cannot plan downstream tool calls or extract required data without knowing response structure.
No tool annotations present. Tools lack readOnlyHint, destructiveHint, or idempotentHint attributes required by current MCP spec (2026-07-28). All tools are READ_ONLY but this is not declared in schema.
No error handling guidance. Tools do not document error conditions (e.g., what happens if codebase parsing fails, if no routes match filters, or if Laravel introspection service is unavailable). Error responses should guide recovery.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | 2026-07-28+ | v2 |
Query the routes in the Laravel codebase by applying various filters based on their names, URIs, associated controllers, applied middleware, or defined parameters. If no filters are provided, all routes will be returned. For most filter categories, you can provide multiple values using `_or` parameters. These values are checked with OR logic, meaning a route will match if it satisfies any of the conditions within that specific parameter (e.g., `name_equals_or: ['login', 'register']` will match routes named "login" OR "register"). Filters applied via `_and` parameters require all provided values to be present (e.g., `uses_middleware_and: ['auth', 'web']` will match routes that use both 'auth' AND 'web' middleware). All distinct filter parameters (e.g., `name_equals_or` and `uses_controller_or`) are checked with AND logic, meaning a route must satisfy conditions from all provided filter categories. Wildcards (`*`) are supported for route name, path (URI), and controller filters. For middleware and parameter filters, exact matching is required.
Query the views in the Laravel codebase by applying filters using view names. Views from libraries and packages are also included in the query. If no filters are provided, all views will be returned, including those from libraries and packages. You can provide multiple values for each filter parameter, which are checked with OR logic (e.g., if you provide `['foo', 'bar']` for `name_equals`, views matching 'foo' OR 'bar' will be included). However, the filters themselves are checked with AND logic (e.g., if you use both `name_equals` and `uses`, the results must satisfy *both* conditions). All name matchers support wildcards (`*`) and will match against absolute view strings, including namespaces (e.g., `filament::*`) and component prefixes (`components...` for `<x-bla-bla />` components). Views named `index` that are placed in a subdirectory will also match on the subdirectory name (e.g., `filament::*button` will match `filament::components.button.index`).
STDIO-only transport. Server uses STDIO protocol, which is not remotely accessible and cannot work with hosted MCP clients. Limits deployment options to local CLI tools and direct integrations.
No pagination or result limiting documented. Tools querying 'all routes', 'all models', 'all classes', or 'all views' may return unbounded result sets, potentially exhausting context windows. Descriptions do not specify result limits or pagination support.