[awongh]

The details on what the architecture of this aren't clear, but I can see that the big feature is deeper integration into the browser.

To me this is an obvious direction for all coding agents to go in. Right now the cursor chrome browser MCP server doesn't work very well, but it's very obvious to me that this is the direction things need to go in.

I'm not sure why focusing on a framework would fundamentally make this any better than the generic approach to getting good context directly from the browser.

[josevalim]

There are two main reasons why being framework specific can be a big boost:

1. We annotate and understand your template language. So when you select an element, we not only know its tag and attributes, but we also know which template file rendered it. The more structured the template language is (JSX, HEEx, etc), the better job we can do, which means LLMs don't have to guess.

2. We also run code within the web framework. This means database access, built-in documentation using the exact versions in your project, access to language and framework reflection/introspection APIs, etc. So the agents have more, err, agency.

I hope this clarifies it a bit!

[towhans]

When using browser-tools-mcp I can point to an element and ask Agent to "change color of this element to red". It would copy the part of the HTML and search the codebase for it.

I can imagine having an in browser, framework level tool would know exactly which controller and which template generated this element and could target it more precisely while using less tool calls and less tokens. I haven't tested it yet but that is my expectation.