Live page evidence
The element, region, and visible state come from the interface you are actually reviewing, not a screenshot someone pasted into chat.
Agent Workflow · Browser Context
Quey starts with the live interface, not a paraphrase of it. Select the UI, capture the change request, expose it to your local provider, and let the agent begin from a source-aware handoff instead of another round of file hunting.
Works with Codex, Claude Code, Cursor, ChatGPT, Windsurf, and other MCP-aware workflows.
What Changes
Quey is not another chat wrapper. It is the missing browser-side evidence layer for UI edits that start from what someone actually selected on the page.
The element, region, and visible state come from the interface you are actually reviewing, not a screenshot someone pasted into chat.
Component clues, selector paths, and source hints reduce file hunting before the first line of code gets touched.
A capture can be acknowledged, replied to, dismissed, or resolved so the request stays visible after the agent finishes.
From Page To Patch
The page tells you what changed. Quey tells the agent where that change came from, how it was requested, and how to report back when the work is done.
01
Pick the exact element or region that needs work in the browser.
02
Quey bundles the change request with layout, copy, and source hints.
03
The local provider makes that capture available through HTTP and MCP inside the repo you want to edit.
04
The agent ships the patch and writes back a summary instead of leaving the fix buried in chat history.
Why It Holds Up
When an agent receives only prose, it has to reconstruct the UI problem from memory and probability. Quey shortens that path by attaching the request to the live page evidence that produced it.
That evidence is small enough to move quickly, structured enough to automate around, and explicit enough to survive a team workflow where designers, reviewers, and engineers are all touching the same request.
Enough context to make the first edit defensible, not lucky.
Target identity: selector path, element type, and visible copy
Source clues: file path hints, component name, and line hints when available
User intent: the request title, body, and change mode
Workflow state: pending, acknowledged, dismissed, or resolved
Surfaces
Quey's agent story is split on purpose: local provider for project-aware edits, MCP for tool interoperability, and a schema contract when you need to wire the data into something custom.
Start the local provider in the repo you want to edit so browser captures land in the right project.
Codex, Claude Code, Cursor, ChatGPT, and other MCP-aware tools can all consume the same structured handoff.
See the contract for what Quey exports when a user selects an element, region, or annotation.
Everything you need to know about Quey for agents
A capture includes the selected target, the user’s requested change, source-aware hints, and the visible browser context that led to the request. The goal is to start the edit from evidence instead of guesswork.
No. Quey is deliberately tool-neutral. The provider exposes the same capture loop through HTTP and MCP so you can plug it into whatever agent workflow your team already uses.
Yes. The extension captures context in the browser, and the local provider exposes that context inside the project you want the agent to edit.
Optionally. There is an auto-run path, but the safer default is a reviewable loop where the agent acknowledges the capture, makes the edit, and resolves it with a summary.
Start With The Page
Install the extension, run the provider inside the repo you want to edit, and let the request begin with selected UI instead of a blurry handoff in chat.
Better prompts matter. Grounded prompts matter more.