Loading ToolBench
Secure remote introspection and control for Laravel applications via HTTP API and MCP
Laravel Kick demonstrates solid tool design with clear naming conventions, comprehensive descriptions, and properly structured schemas. All 8 tools are explicitly defined with input/output schemas and follow verb_noun naming patterns (kick_health, kick_stats, kick_logs_read, etc.). Descriptions are well-written and range from 150-250 characters, explaining WHAT each tool does and WHEN to use it. Tool annotations (#[IsReadOnly], #[IsDestructive], #[IsIdempotent]) are correctly applied. However, there are gaps in parameter constraints (enums missing where beneficial), some parameter descriptions are generic, and error handling guidance is minimal. Output schemas are documented but could be more explicit about chaining IDs for common follow-up operations.
List all whitelisted artisan commands that can be executed through Kick. Only these commands are allowed for security.
Execute a whitelisted artisan command. Use kick_artisan_list to see available commands. The whitelist is configured in config/kick.php.
Check Laravel application health including database, cache, and storage. Redis is checked when used for session or queue (but not when cache already uses Redis). Returns status and latency for each service.
List available Laravel log files with their sizes and last modified timestamps.
Read entries from a Laravel log file. Supports filtering by log level (DEBUG, INFO, WARNING, ERROR, CRITICAL, ALERT, EMERGENCY) and searching within messages.
Retry failed queue jobs. Can retry a specific job by ID or all failed jobs.
Parameter 'level' in kick_logs_read lacks context-sensitive guidance. Description states enum values but does not explain when to use each level or note that filtering is optional.
kick_queue_retry accepts mutually exclusive parameters (job_id vs retry_all) but the description does not explicitly state the mutual exclusivity. This forces the LLM to infer the constraint.
Error handling in kick_artisan_run returns a helpful list of available commands on CommandNotAllowedException, but the output schema and tool description do not document that a 'success' field will be false in error cases, or how to distinguish success from failure in structured output.
kick_stats description mentions 'container-aware' and 'cgroups v1/v2' without explaining what signals the LLM should look for in the response to determine if container metrics are available. Agents cannot infer this from the tool alone.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 69 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Get queue status including job counts per queue, failed job count, and connection info. Optionally list failed jobs with their details.
Get system/container statistics including CPU load, memory usage, disk space, and uptime. Container-aware using cgroups v1/v2 when available.
No pagination parameters visible for tools that list resources (kick_logs_list, kick_artisan_list, kick_queue_status with include_failed=true). If these return large result sets, pagination must be supported to prevent context window exhaustion.
Parameter descriptions for 'arguments' in kick_artisan_run state 'key-value pairs' but do not specify the expected structure (flat object, nested, boolean flags, string values only?). This ambiguity forces the LLM to guess the format.