Introduction
When I am doing frontend development, quite often I find myself struggling to explain the visual issue in sufficient detail to an LLM assistant (ChatGPT / Cursor etc.):
It usually goes like: “So there’s 2 boxes – more like panels, they are next to each other.. They have texts within each, and buttons under each, the left one is not aligned to the bottom of the panel it is sitting in…”
Of course it doesn’t paint the full picture, so the LLM comes back with some assumed parts, resulting in a less than ideal fix – and I have to add more detail of what I see, reprompt. Rinse and repeat.
What if instead, I could just point at the elements, or better yet, select the area I am talking about, and just “Say the change I want to see”…
Sounds exciting? Great! This is exactly what we are making possible with our new TestChimp Chrome Extension + TestChimp Cursor extension.
Try it out
Here is the setup:
Install the chrome extension from here.
Install (and start) the Cursor extension from here.
I assume you have a site you are working on – and is doing hot-reloading during dev (npm start dev or equivalent).
Now navigate to your localhost webapp in the browser. Open the TestChimp Chrome extension (and login with your TestChimp account).
You should see something like the above. Now Click on the Plus Icon in the Add Context box. You can either select an element on the page, or select an area on your page (around the issue you are looking to fix).
On the prompt box, just say the change you want done.
Click Send to IDE (Make sure VSCode connection status shows “Connected”. If it isn’t, that means you haven’t started the extension in Cursor. Open the command palette and run “Start TestChimp Bridge”).
Go to your IDE, and you should see a detailed prompt copied to a new chat thread with Cursors’ AI. Just hit the send button, and Cursor will get to work on the request – equipped with the full visual context – enabling it to resolve the issue accurately.
What’s in the prompt?
Ok, let’s dig into the details now. Along with the instructions you added, the chrome extension captures metadata about the elements / areas you selected to give the AI richer context:
For elements:
- Identifying metadata such as text, role, selector, any ids, css classes – helpful for locating the element in the code.
- Computed styles – these are helpful for understanding the final result of the code, and figuring out root cause of styling issues
- Ancestry hierarchy – A common issue when prompting to solve visual glitches is giving the structural location of the element of interest, and how it relates to the rest of the components (since parent styles, positioning affect the child components).
- Bounding box – To visualize the location on screen, useful for location related issue resolution
For areas:
- It identifies the top level components that fall within the area you selected, and sends the above information about those elements
- Bounding box of the selected area
In addition to those, it also sends relative URL of the current page – useful for file resolution when additional metadata is lacking.
It captures additional “Extra information” about elements too (such as complete attributes, querySelector, complete text content, outer html etc.) – which can be requested on demand by the IDE, via our MCP server (More on that below).
The above is the basic setup (Chrome extension + VSCode extension). There are a couple of additional pieces that can supercharge your visual vibe coding experience:
Babel-plugin-source-mapper: Optional
(LINK)
This is a small Babel plugin that we authored, which instruments your build with source file metadata – in each of your jsx components (React components).
How to use it? Just add it as a plugin to your dev build script, and you are all set. The exact setup depends on your stack, but here is a quick sample with Craco: [link].
With this added, Chrome extension can now extract the source file paths that are relevant to the current screen during runtime (and the elements / areas you selected), making it significantly easier for Cursor to get to the proper resolution quicker (since it doesn’t need to scan through the whole code base, and run into false positive paths). Essentially, this allows you to bridge your static code with the runtime behaviour.
TestChimp MCP Server: Optional
(Documentation Link)
So far, the interaction with Cursor has been one-shot. The Chrome extension collects the relevant information, and prompts the IDE once. What if we could provide the IDE a way to query for additional information, and go back and forth “talking” with your browser as needed to get the fix you requested done properly?
This is where the MCP server kicks in.
MCP stands for Model Context Protocol, a standardized approach for LLM agents to talk with each other. MCP servers provide “tools” that MCP clients (such as Cursor, Windsurf etc.) can use based on the job at hand. The TestChimp MCP server exposes the following 7 tools currently:
Current browser state related
get_recent_console_logs
Enables your IDE to query for recent logs (of a certain log level, since a given timestamp etc. – Great for getting deeper context about functional issues
get_recent_request_response_pairs
Similar to above, this provides redacted, PII filtered, request and response header pairs of recent. This can be useful for identifying backend interaction issues (if the server is returning error codes, causing the frontend behaviour etc.)
get_dom_snapshot
With this, your IDE can request an LLM friendly filtered version of the current screen, to get the broader context about what is on the screen – useful for solving many visual / layout issues
fetch_extra_info_for_context_item
When the extension prompts about the context items, it provides a unique reference ID for each item. If the IDE decides it wants to dig deeper into more details about a certain item, it can request them with this tool. For the above 4 tools, our MCP server communicates with the chrome extension to fetch information about the current browser state and returns to the IDE.
Application runtime behaviour context related
AI enabled IDEs have great context about your static codebase, but they lack context about the “Runtime behaviour” of your application, since various components are assembled during runtime to facilitate user journeys and conditionally branch out based on user interactions.
This is where TestChimps’ AI agent: ExploreChimp helps.
ExploreChimp is an AI agent that crawls through your application (think of it as an LLM enabled version of a Google crawler), to build a comprehensive understanding of the *Runtime behaviour Graph* (a.k.a MindMap), capturing:
- the different screens in your app
- the states they can be in
- the pathways through the app
- detailed down to individual element level – an indexing of your UIs of runtime
This MindMap is made available to your IDE via our MCP server, for higher granularity reasoning tasks, enabling your IDE to effectively break down tasks and target correct components to update.
The MCP exposes the following 3 tools to your IDE relating to the MindMap:
get_runtime_behaviour_graph
This returns an overview of the runtime behaviour graph that TestChimp has built about your webapp (capturing different screens, states, pathways, and additional metadata such as related file paths etc.)
get_ui_node_details
ask_runtime_behaviour
This allows Cursor to communicate in free text and ask questions about the runtime behaviour in free form, for any specific information it wants for the current task: an agent to agent plain english collaboration.
For more information about how to set up the MCP Server, refer here.
Below is the diagram showcasing how different components interact for the full setup:
