find
Describe a page element in plain language to locate it in Firefox. Returns ranked ref handles ready for action tools by matching accessible names, text, and attributes.
Instructions
Look up elements by describing them in ordinary language instead of by selector: "the search box at the top", "whatever button adds this to a cart", "the heading that mentions pricing". Scoring runs over the same tree read_page builds - accessible names, an element's own text, and attributes such as id, name, placeholder, title and href - with extra weight for a handful of intents (search, login, cart, menu, close, submit, dropdown, checkbox, heading). Results come back ranked, best first, each with the ref_N handle the action tools need, and at most 20 are printed; when more than that matched, the output tells you to describe the target more tightly. The search reaches 30 levels deep and the first 5000 elements walked, and it says so when it stopped short - so an empty result on a huge page means widen the net with read_page, not that the element is absent. query and tabId are both required, and handles expire with the document, so run find again after any navigation; a browser_batch step must state the id itself. As everywhere on this server the automation profile skips any per-site approval step, while an unanswered alert or confirm holds the page until firefox_dialog clears it.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Describe the target the way you would to a person: by its job ("login button", "the search field in the header") or by wording visible on it ("Add to cart", "organic mango"). A few concrete words beat a full sentence; filler such as "the", "please" and "click" is dropped before matching. | |
| tabId | Yes | Required: the session tab to search. Ask tabs_context_mcp or firefox_status for valid ids; only the tabs this session owns are addressable, and a browser_batch step must spell the id out. |