Great questions!
That particular example had the MCP tell the precise LiveView active on the page, which is not as straight-forward to get from a browser MCP (doable but then you had to write your own JS traversal scripts). This reveals the two important parts about Tidewave: it runs inside your application, so it has access to everything your application does, and it is fine-tuned for your specific web framework.
For example, one of the tools Tidewave offers is access to the database. Surely you can do this with another MCP, but your app already has access to the database, with all of the credentials and configs you would need, and that saves you work. Plus the tool has the ability to query your database using SQL or using your language’s query builder. And this applies to everything: access to background queue? Check, Access to the APIs you talk to? Check. Most of it is powered by the project_eval tool, where we evaluate code within your running application instance.
Another tool that we offer is to get the package documentation. Many people are asking for llms.txt (which I agree are useful) but, when working on a project, all of the packages and their documentations are already available on your machine, with the exact version your application uses. This also applies to getting the location where packages are installed or the file+line of where modules and functions are defined. Those are all things that could be done separately but, because Tidewave is literally running within your web app, we can ask the language runtime/compiler, which will just do a better/faster job.
For any of these goals - will a graph database help? in which way? I am not yet clear. On the otherhand, we can already see that these dynamic intervention with something like Tidewave is leading to some real benefits with development. If not in generation - atleast in debugging. Maybe it should be enhanced more by integrating something like PlayWright MCP. But, beyond that probably I am not sure if we need more interventions.