Reports whether the OmniSnap browser extension is paired with this server, and which tab is active. Call this first when any other OmniSnap tool fails, and to get pairing instructions.

Lists the open browser tabs OmniSnap can act on, with their titles and URLs. Use it to find the right tab before capturing or collecting selectors.

Takes a screenshot of the active tab and returns it as an image the model can see. Captures the full scrollable page by default, including pages that scroll inside a panel. Use it to check layout, verify a fix visually, or see what the user is describing.

Screenshots a single element, given a CSS selector. Cheaper and far easier to reason about than a full page when the question is about one component.

Returns a screenshot with every interactive element outlined and numbered, plus a table mapping each number to its best selector and a stability score. This is the tool to use before acting on a page: look at the image, pick a number, then use that number's selector. Far more reliable than guessing a selector from the DOM.

Given a description or a CSS hint, returns every selector that could reach the element, ranked by how likely it is to survive a redeploy and checked against the live page so you know whether it matches one element or several. Prefer the top result. A selector built on a generated class such as css-1x2y3z is scored down because it changes whenever the bundler runs.

Exports the selectors collected in the browser as a ready page object. The best selector differs per framework: Playwright can match a role and an accessible name, Selenium cannot and falls back to CSS or XPath for the same element, so always pass the framework you are actually writing for.

Takes a list of selectors and reports, for each, how many elements it matches on the page now. Use it to find selectors that have rotted after a UI change, before a test run does.

Returns Web Vitals, failed and slow network requests, console errors, storage use and the exact browser environment for the active tab. This is measured in the user's real session, so it reflects their network, their extensions and their data, which a clean automated browser cannot show you.

Extracts the design system the page actually uses: palette with contrast audit, type scale, radii, shadows and spacing. Use it to match a new component to an existing product, or to find accessibility problems in the live UI.

Audits the live page for contrast failures, missing accessible names, skipped heading levels and touch targets below the minimum size. Returns the offending elements with selectors.

Returns the box model, computed typography, colours and spacing for a single element. Use it when a design question needs numbers rather than a picture.

Scrolls the page. Use it to see the rest of a page: annotate_interactive and the screenshots only cover what is on screen, and its "coverage" field says how much of the page that is. Scroll, then capture again. This moves the camera, not the hands: it cannot click, type or navigate.

Arms the element picker in the browser and waits for the user to click the elements they mean, then returns them with ranked selectors. Use this instead of guessing when a page has several things that match the description ("the save button", "that broken card"), or when you cannot find what the user is describing. Asking costs one turn; picking the wrong element costs the whole task.

Returns the page's text and heading outline. Use this first when the question is what the page says rather than what it looks like: it costs a fortieth of a screenshot and a model reads a paragraph far more reliably than a picture of one. Reach for a capture when the question is visual.

Proposes clicking an element or typing into a field. The extension outlines the element and asks the user to approve; nothing happens unless they do. Use it to reach states that only exist after an interaction: an open menu, a validation error, the next step of a form. That is where most defects are. The user may decline. If they do, do not retry: ask them what they want instead.

Holds the page at a phone, tablet or desktop width, and leaves it there. Every tool afterwards, including the numbered map, the accessibility audit and the measurements, then answers about that width, which is how you find what is wrong at 375px rather than just noticing that something is. Call it with reset to give the page back. Chrome shows a debugging banner while this is held; that is Chrome, not the page.

Shows the page as if the user preferred light or dark, without them changing anything. Dark mode is where contrast regressions hide, because it is the theme nobody screenshots. Use "auto" to hand it back.

Puts the pointer on an element and returns a screenshot of what that reveals: dropdowns, tooltips, hover styling. These states cannot be reached any other way: a synthetic event fires the page handlers but leaves the CSS untouched, so this uses a real pointer move. Nothing is clicked.

Focuses an element and returns a screenshot. Use it to check focus rings, which are the most commonly missing accessibility feature and are invisible in an ordinary capture.

Watches the page for a number of seconds and reports the console errors, failed requests and layout shifts that happen during it. Every other tool here asks a question and gets an answer as of that instant; most of what goes wrong does not wait to be asked. Use it while the user reproduces something, or just after a change, when asking afterwards would find a page that looks fine.

Captures the full page at phone, tablet and desktop widths and returns them side by side in one image. Use it to check a responsive change in a single look, rather than three captures you have to hold in mind at once.