Debug a failed Laravel job with LaraBench MCP

Direct answer

Set the LaraBench connection to Read only first. Ask the agent to inspect recent Laravel logs with read_logs and prior LaraBench runs with get_run_history. If it proposes a runtime check, inspect the run_snippet call before granting Dry run. Retry the failed job yourself after you confirm the cause.

When to use this

Use this when a queue job has failed and the useful context is split between the exception log, the job's configuration, and a previous diagnostic run. LaraBench exposes named tools to Claude, Codex, and Cursor. The agent receives the requested tool results, not SSH credentials, private key paths, or the full project filesystem.

Terminal approach

Start with the same checks you would run manually. List failed jobs, inspect the relevant log entry, and identify the job class before changing anything:

php artisan queue:failed
tail -n 200 storage/logs/laravel.log

Search by exception class, job UUID, or a stable message from the failed handler. Retry only after the dependency, data, or code that caused the failure has been fixed.

Agent workflow

1. Ask the agent to call list_connections and use the intended non-production or read-only connection.
2. Ask it to read only the relevant warning or error entries with read_logs.
3. Use get_run_history to compare the exception with recent commands, outputs, exit codes, and query counts.
4. Review any proposed run_snippet call before it executes. MCP run and save tools require Premium.
5. Confirm the diagnosis yourself before running queue:retry {jobId}.

Diagnostic snippet

Keep the runtime check narrow. For example, verify the queue connection and a dependency binding without dispatching a job:

return [
    'environment' => app()->environment(),
    'queue_connection' => config('queue.default'),
    'job_service' => get_class(app(App\Services\JobService::class)),
];

Replace JobService with the service used by the failed job. This reads booted configuration and resolves a binding; it does not dispatch or retry work.

Expected result

A useful response names the relevant log entry, a matching History run, the likely cause, and the exact read-only check used to confirm it. Runs made through MCP appear in LaraBench History with an AI badge.

Troubleshooting

• If the connection is missing, check its AI access level on the MCP Server page. Production starts hidden.
• If remote logs cannot be read, keep LaraBench open so it can use the SSH or Docker connection.
• If run_snippet is unavailable, confirm the desktop user has Premium and the app is open.
• If the agent asks for broad logs, narrow the level, file, and search term before approving the read.

Safety notes

Start with Read only. Use Dry run only when code execution is necessary. Production connections remain off until you opt them in, and a production write still waits for approval in LaraBench. Dry run cannot prevent every external side effect, so avoid snippets that send mail, call APIs, publish events, or push queue jobs.

Related workflows

Read the remote log workflow before granting code execution, then use the single failed-job retry workflow once the cause is fixed.