Boost's tinker requires explicit return statement and semicolon

[shortontech]

Boost Version

1.8.10

Laravel Version

12.42.0

Agent/IDE Name & Version

Claude Code 2.1.12

PHP Version

8.5.2

System Info

Ubuntu 24.04

Description

I've used skills with Claude to provoke it to use artisan tinker, and that's gone well. Anthropic's Claude Sonnet 4.5 has a lot of training data regarding how to use Tinker, so that has worked well for me.

One of the normal features of php artisan tinker is that if you use it to run a query or a function, you don't have to be explicit with a return statement, and you don't need a semicolon.

Boost's tinker requires a return statement and a semicolon to return data.

Steps To Reproduce

From the Claude Code CLI, ask it to run simple PHP code, without the semicolon.

❯ Use the mcp's tinker and see if you can execute "echo 1"

● laravel-boost - tinker (MCP)(code: "echo 1", timeout: 180)
  ⎿  {
         "error": "syntax error, unexpected end of file, expecting \",\" or \";\"",
         "type": "ParseError",
         "file": "vendor\/laravel\/boost\/src\/Mcp\/Tools\/Tinker.php(53) : eval()'d code",
         "line": 1
     }

Using the command line:

php artisan tinker --execute='echo 1'

This just prints the number 1.

[soleinjast]

Hey @pushpak1300 👋

I’ve been looking into this and it seems like it can be addressed with a small, low-risk change. The issue appears to come from MCP Tinker executing raw PHP via eval(), which causes missing semicolons and expression-only snippets to behave differently from php artisan tinker.

My idea would be to slightly normalize the input before execution — for example, appending a trailing semicolon when it’s missing and safely auto-returning pure expression snippets, while keeping assignments and other statements behaving exactly as they do now. This would preserve existing behavior, avoid pulling in full PsySH complexity, and improve compatibility with common Tinker usage, especially for AI-generated snippets.

If that sounds reasonable to you, I’m happy to open a PR and work on it 👍

[pushpak1300]

What I’m thinking is: instead of running things manually, we could wrap PHP Tinker’s “execution” mode directly inside the tool. That way we don’t have to do a bunch of extra work ourselves.

For example, all the handling we currently do in the ListRoutes tool would be handled in the Tinker tool. It would basically just be a thin layer on top of Tinker, so we don’t have to handle each edge case separately.

What do you think? @soleinjast

[soleinjast]

@pushpak1300

Sorry for the slow reply — I missed your comment earlier.

This makes sense, and I agree with the direction. Using real Tinker execution as the foundation would give us correct behavior by default and avoid re-implementing Tinker semantics inside MCP. It also feels like the right long-term move if it lets us rely less on purpose-built inspection tools like ListRoutes.

The main thing I’d want to sanity-check is how well artisan tinker --execute fits MCP’s single-shot execution model in practice — mainly the process overhead per call and how usable the output is for MCP consumers when it’s mostly plain text rather than structured data. I don’t see those as blockers, just things worth validating.

If you’re happy with that approach, I can put together a small spike that wraps Tinker’s execution mode!