project_evalLABSCO SUMMARY
The agent stops guessing about your app because it can ask the app.
Evaluating code inside the booted application is the tool that changes how an agent works on Rails: instead of reasoning about what a model returns, it runs the line and reads the answer, with the logs and the database covering the two places the truth usually hides. That reach is why the gem is development-only — it refuses to start where code reloading is off, and stays bound to localhost until you deliberately open it.
What it is
A gem added to a Rails app's development group. It runs inside the running application and serves MCP over HTTP at /tidewave/mcp on the port your app already uses, so the agent talks to the booted app rather than to a copy of its source.
What you get
- Ruby evaluated in the context of the running application, with its loaded dependencies and in-memory data — the result plus anything printed, like a Rails console the agent can use
- SQL run against the development database, so the agent can seed realistic records or check that a create action saved what it should have
- The server log read back, which is where the params, the backtrace and what actually happened after a request are
- Documentation for a class, method or constant, read from the exact gem versions pinned in Gemfile.lock rather than from training data
- The file and line where something is defined, across the app and its gems — resolved from the running app, so a method generated at runtime is found where grep would miss it
Requirements
A Rails app you can add the gem to as a development-group dependency, and a client that speaks streamable HTTP — point it at http://localhost:3000/tidewave/mcp, or whichever port the app runs on. It raises rather than boot in any environment where code reloading is disabled, which normally includes production, and accepts requests from localhost only unless allow_remote_access is turned on. There are deliberately no tools for listing routes or associations: the author's position is that an agent reading those source files gets more context and can edit them in the same pass.
Setup effort
One command — bundle add tidewave --group development
USE CASES
Checking what a method really returns
Run the call inside the running app instead of reasoning about the source, and read the result and anything it printed.
Reproducing a bug against live state
Run the failing path in the app's own context, then read the log and backtrace it produced.
Seeing a page with realistic data
Insert the test records with SQL against the development database, then check what the request did with them.
Finding where something is actually defined
Get the file and line from the running app — including a method a gem generated at runtime, which no grep will find.
Using a gem API correctly the first time
Read the documentation for the version your Gemfile.lock pins, not the version the model happens to remember.
5 tools
Listed in project docs. Your client may show a different list.
execute_sql_queryget_docsget_logsget_source_locationBEFORE YOU INSTALL
What to know first
Tools you get
5 tools named in the project's documentation.
INSTALLATION
Connect your client
Server setup
bundle add tidewave --group developmentOr manually add gem "tidewave", group: :development to your Gemfile.
Add the Tidewave MCP server to your editor / MCP client configuration as type "http" (streamable) pointing at http://localhost:3000/tidewave/mcp