ego-webqa

Overview Schema Source Related Servers Discussions Admin

Audit generated web page

audit_web_page

Audit a generated web page in a real browser to verify delivery usability, mobile viewport, text scaling, safe-area behavior, and CTA flow; return screenshots and machine-readable evidence.

Instructions

Audit a generated page in a real browser and return deterministic evidence.

Provide exactly one of url or directory. The result is blocked when the page has a delivery error; warnings remain visible but do not block unless fail_on_warn is enabled in the JSON config. This checks delivery usability, not security, WCAG conformance, visual regression, or real-device Safari parity. Use browser_engine="webkit" for a WebKit approximation only.

Input Schema

Name	Required	Default
`url`	No
`file`	No	index.html
`smoke`	No
`config`	No
`out_dir`	No
`profile`	No	baseline
`directory`	No
`viewports`	No
`timeout_ms`	No
`smoke_scope`	No	first
`browser_engine`	No
`ready_selector`	No
`smoke_selector`	No
`smoke_flow_name`	No
`smoke_settle_ms`	No
`viewport_preset`	No
`wait_for_network_idle`	No
`smoke_success_selector`	No
`smoke_require_assertion`	No
`smoke_success_url_pattern`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.8.2Oct 30, 2026

addedInput schema / properties / browser_engine

Added value: +{
+  "default": "",
+  "title": "Browser Engine",
+  "type": "string"
+}

addedInput schema / properties / smoke_flow_name

Added value: +{
+  "default": "",
+  "title": "Smoke Flow Name",
+  "type": "string"
+}

addedInput schema / properties / viewport_preset

Added value: +{
+  "default": "",
+  "title": "Viewport Preset",
+  "type": "string"
+}

First observedv0.4.2Oct 29, 2026

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the full behavioral burden. It does disclose genuinely useful semantics: delivery errors block the result, warnings only block when `fail_on_warn` is set, and webkit is only an approximation. However, nothing is said about what 'evidence' is returned, whether artifacts are written to disk (out_dir), or the cost/runtime of a real-browser run — significant gaps for a mutation-adjacent, 20-parameter tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, front-loaded with the core action and with zero filler. The negative-scope and engine-caveat sentences each earn their place, though the config/warn sentence is dense and could be split for scanability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 20 inputs, no annotations, no output schema, and 0% schema description coverage, the description accounts for only a small fraction of the surface. It never explains the smoke-test parameters that dominate the schema, what gets returned, or where evidence lands — an agent could not invoke this correctly for anything beyond the simplest url-only call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 20 parameters, so the description must compensate and it does not. It clarifies only three of the twenty inputs (url/directory mutual exclusivity, browser_engine='webkit', and that fail_on_warn lives in the JSON config); smoke_*, viewports, profile, ready_selector, timeout_ms and the rest are left entirely opaque.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb and resource ('Audit a generated page in a real browser') plus the deliverable ('deterministic evidence'). The negative scope sentence ('checks delivery usability, not security, WCAG conformance, visual regression, or real-device Safari parity') further sharpens what the tool actually is, so an agent has an unambiguous picture of purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a hard invocation constraint — 'Provide exactly one of `url` or `directory`' — and explicitly excludes adjacent use cases (security, WCAG, visual regression, Safari parity), which functions as guidance on when not to use it. What's missing is any positive statement of the scenario that should select this tool, so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools

audit_web_pageA