Loading ToolBench
Secure remote introspection and control for Laravel applications via HTTP API and MCP
Laravel Kick demonstrates solid engineering with 8 well-named tools covering health checks, logging, queue management, and artisan command execution. All tools have clear descriptions (100-300+ chars), comprehensive input schemas with enums and constraints, and output schemas. Tool annotations (IsReadOnly, IsDestructive, IsIdempotent) are properly applied. Key strengths: verb_noun naming convention, parameter constraints, structured output with both text and JSON. Key weakness: three tools (kick_health, kick_stats, kick_logs_list) lack documented output schemas in code, only 5 of 8 have explicit outputSchema() implementations visible. Parameter descriptions are detailed and include constraints. Error handling is present but recovery guidance is minimal in some tools.
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.
Three tools lack visible output schema documentation: kick_health, kick_stats, kick_logs_list do not show explicit outputSchema() implementations in provided source. Without documented output schemas, LLMs cannot plan downstream tool composition or know what fields to extract.
Error recovery guidance is minimal. kick_artisan_run returns available commands in error responses (good), but other tools lack actionable next steps. E.g., kick_queue_retry failing on invalid job_id should suggest 'Use kick_queue_status with include_failed=true to find valid job IDs.'
kick_artisan_run is a destructive tool with no dry-run or confirmation mechanism. Agents could accidentally run destructive commands (e.g., 'php artisan migrate:reset'). Consider adding a 'dry_run' boolean parameter or requiring explicit confirmation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 64 | 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.
kick_logs_read accepts 'limit' parameter with default 100 and max 500, but no pagination/cursor mechanism is documented. Large log files could return truncated results without clear indication of whether more entries exist. Should include 'total' count or 'has_more' flag in output.
No tool for permission/capability discovery. LLMs cannot know in advance which artisan commands are whitelisted without calling kick_artisan_list first. This is acceptable, but no mechanism exists to pre-filter by user/role permissions, all whitelisted commands are visible to all callers.