Cognitive browser automation that thinks like your users—and helps AI agents navigate too. Simulate real user cognition with abandonment detection, constitutional safety, chaos engineering, and UX friction discovery.
CBrowser provides 13 tools with mostly complete schemas and descriptions. Naming is action-oriented (ask_user, hover, type_text, press_key, handle_dialog, upload_file, drag, analyze_page, generate_tests, find_element_by_intent, ai_benchmark, artifact_fetch, assert). Descriptions range from adequate to strong (most 80-250 chars). However, several tools lack sufficient guidance on WHEN to use them vs similar tools, dependency documentation is sparse, and error handling/recovery guidance is minimal. Tool composition is reasonable but some tools mix concerns (e.g., analyze_page conflates structure analysis with form/button/link detection). The _browserToken parameter is consistently required across interaction tools but its semantics and lifecycle are not well documented. Output schemas are largely undocumented in the provided code samples.
Compare AI-friendliness across competitor sites. Runs agent-ready audits on each URL, ranks by AI readiness grade, and identifies what each competitor does better for AI agents. Use for competitive intelligence on AI-readiness.
Analyze page structure for forms, buttons, links. MUST pass _browserToken from a previous tool call to analyze the same page — without it a blank page is analyzed and every count comes back zero.
Fetch a generated image artifact (heatmap, diff, capture frame) as inline image data. Called by interactive views to display images the widget sandbox cannot load by URL; not usually needed directly.
Create a structured prompt to ask the user a question. Returns AskUserQuestion-compatible format. Use this when you need user input before proceeding. Claude should present this to the user and return their selection.
Assert a condition using natural language
Drag an element to a target location. Simulates mouse press, move, and release.
Missing output schemas: 10 of 13 tools lack documented return type structures. Tools like analyze_page, generate_tests, ai_benchmark do not specify what fields/structure they return. This forces LLMs to infer or guess, leading to incorrect downstream tool selection.
_browserToken lifecycle and semantics are undocumented. Tools require this token from 'previous tool calls' but no tool description explains what it is, how to obtain it initially, how long it persists, or what happens if an stale/invalid token is passed. This creates a critical dependency that LLMs cannot safely reason about.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | 1.25.3+ | v1 |
AI-powered semantic element finding with ARIA-first selector strategy. Prioritizes aria-label > role > semantic HTML > ID > name > class. Returns selectorType, accessibilityScore (0-1), and alternatives. Use verbose=true for enriched failure responses.
Generate test scenarios for a page
ARM a handler for the next JavaScript dialog (alert, confirm, prompt), then trigger the dialog with a separate call. Returns immediately once armed — the handler persists until a dialog fires, so it does NOT need to observe one to have worked. For prompts, provide the text to enter.
Hover over an element to trigger tooltips, dropdowns, or hover states. Uses CSS selector or smart selector.
Press a keyboard key (Enter, Tab, Escape, ArrowDown, Backspace, etc). Supports modifier combos: 'Control+a', 'Shift+Enter', 'Meta+c'. Full list: https://developer.mozilla.org/en-US/docs/Web/API/UI_Events/Keyboard_event_key_values
Type text character by character using keyboard events. Unlike 'fill', this triggers keydown/keypress/keyup events for each character. Use for inputs that need real keyboard events (autocomplete, search-as-you-type, game inputs).
Upload file(s) to a file input element. Works with <input type='file'> elements.
Insufficient error handling guidance. No tool description explains what errors can occur, how to interpret them, or what the LLM should do next (retry, ask user, fallback). For example, if upload_file fails because the file does not exist or press_key fails because the element is not focused, the LLM has no recovery path.
Missing 'when to use' guidance. Several tools have similar semantics and could be confused by LLMs. For example: drag vs click for interaction, find_element_by_intent vs analyzing page to find elements, hover vs click. Descriptions lack explicit guidance on when each tool is the right choice.
Generic or weak descriptions on 5 tools reduce discoverability. 'Generate test scenarios for a page' (40 chars) and 'Hover over an element to trigger tooltips, dropdowns, or hover states' (70 chars) lack sufficient context. Descriptions should explain WHAT the tool returns, WHEN to call it, and key parameters.
Conditional parameter dependencies not enforced in schema. generate_tests documents that _browserToken is 'required when url is omitted' but JSON Schema has no way to express this constraint (oneOf, not just description text). LLMs may pass neither or both, causing errors.
Underspecified selector semantics. Multiple tools (hover, drag, upload_file) accept 'CSS selector or text description' but what counts as 'text description'? Is it fuzzy matching, exact substring match, or semantic intent like find_element_by_intent? This ambiguity invites misuse.