Loading ToolBench
Laravel Loop is an MCP (Model Context Protocol) Server for Laravel
Laravel Loop provides 6 tools with mixed quality. Most tools lack comprehensive input schemas, parameter descriptions are minimal or missing, and output structures are not documented. Tool naming follows some conventions (verb_noun for 4/6 tools), but descriptions are inconsistent in depth. Critical gaps include missing enum constraints on string parameters, undocumented response schemas, and no error handling guidance. The stripe_tool is particularly problematic: it accepts raw HTTP methods and bodies with minimal validation guidance, creating security and usability risks. Factory and model tools have slightly better descriptions but still lack detailed parameter documentation.
Creates one or more model instances of test data using a specified Laravel factory, optionally applying states and overriding attributes.
Lists all available Laravel factories, their models, and public methods (states) to be able to create test data in the application.
make a call to the stripe api. You can use this tool to fetch any stripe related data. Please double check with the user for any non-GET requests.
Get detailed information about the users table, with all its fields and relationships.
Fetch a specific user by ID or its primary key.
List all users. You can filter results by using the fields from the describe tool.
stripe_tool accepts raw HTTP method strings (GET, POST, PUT, DELETE) without enum constraint. LLMs can hallucinate invalid methods like 'PATCH' or 'GETT'. Should define methods as enum ['GET', 'POST', 'PUT', 'DELETE'].
stripe_tool description says 'Please double check with the user for any non-GET requests' but provides no programmatic enforcement or confirmation mechanism. No dry-run, no pre-execution validation, no recovery path if the LLM makes a mistake. Destructive Stripe operations (refunds, deletions, charge reversals) lack safeguards.
stripe_tool lacks output schema documentation. No mention of what response fields to expect, whether errors return partial results, or how the LLM should interpret Stripe API responses. Tools returning HTTP responses should document the JSON structure.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
user_list_models accepts a nested 'data' object containing filters, limit, order_by, and order_direction. The schema structure is opaque, no enum for order_direction (asc|desc), no range constraint on limit, no documentation of filter JSON format. LLMs cannot construct valid filters without trial-and-error.
user_list_models, user_find_model, and user_describe_model use prefixes like 'user_' instead of model-agnostic names. The codebase shows LaravelModelToolkit generates tools per model (User, Post, etc.), meaning a full setup will have duplicate naming patterns (user_*, post_*, comment_*, etc.). This scales poorly, tool names become ambiguous when dozens exist. Consider generic list_model, find_model, describe_model with model_name parameter.
No input schemas visible for laravel_factories_describe or user_describe_model, which show Input: {}. While these are read-only discovery tools and may legitimately take no parameters, the lack of any schema definition (even an empty object schema) makes them harder for clients to validate. Explicitly document that they take no input.
laravel_factories_create accepts 'states' and 'attributes' as arrays/objects but provides no schema for what valid states are or what attributes are allowed per factory. LLMs must guess or call laravel_factories_describe first, then reverse-engineer the relationship. Add examples or validation guidance.
No error handling guidance across any tool. None describe what happens if a model is not found, if Stripe API returns 401 Unauthorized, if a factory name is invalid, etc. LLMs have no recovery path, they see an error and must retry blindly or ask the user.
stripe_tool embeds Stripe API directly without access control. No mention of permission checks, token validation, or rate limits. An untrusted agent could abuse this to make arbitrary Stripe calls (refunds, charge disputes, etc.) without guardrails.
user_list_models and user_find_model descriptions do not mention pagination, result limits, or how many items will be returned. If a database has 10,000 users and list_models returns all of them, the context window will explode. No mention of limit defaults or maximum result caps.