Skip to main content
Glama

validate_url

Assesses accuracy of predicted screen-reader navigation by simulating virtual screen reader interactions and comparing step counts.

Instructions

Validate Tactual's predicted navigation paths against a virtual screen reader. Runs analyze_url internally, then for each worst finding drives @guidepup/virtual-screen-reader over the captured DOM (via jsdom) to check: (a) is the target reachable at all, and (b) how many virtual SR announcements does it take to reach it? Compares to Tactual's predicted step count. Returns an accuracy ratio per target and a mean across all validated targets — closer to 1.0 means Tactual's predictions match this virtual-screen-reader run, not a guarantee of full real-AT fidelity.

Requires (optional deps): jsdom + @guidepup/virtual-screen-reader. Installed with tactual if optionalDependencies were honored; otherwise run npm install jsdom @guidepup/virtual-screen-reader in your project.

When to use: closing the modeled-vs-virtual loop. If Tactual's predictions diverge a lot from the virtual SR, either the profile weights need calibration or the page has structural patterns the analyzer doesn't model. Use sparingly — this adds the analyze_url cost plus jsdom parsing + virtual SR navigation time.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesURL to analyze and validate
profileNoAT profile ID (default: nvda-desktop-v0). Use list_profiles to see options.
maxTargetsNoMaximum findings to validate (worst-first). Higher = slower but more signal.
strategyNoNavigation strategy for the virtual SR. 'linear' uses Tab/Shift-Tab (keyboard flow); 'semantic' uses heading/landmark skip commands (screen-reader flow). Semantic is more representative for NVDA/JAWS/VoiceOver users.semantic
timeoutNoPage load timeout in ms
waitTimeNoAdditional wait after load (ms)
channelNoBrowser channel: chrome, chrome-beta, msedge
stealthNoApply anti-bot-detection defaults
storageStateNoPath to a Playwright storageState JSON (for authenticated pages). Must be within the current working directory.
Behavior4/5

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

With no annotations, the description fully explains behavior: it runs analyze_url internally, drives @guidepup/virtual-screen-reader, checks reachability and step count, and returns accuracy ratios. It also mentions optional dependencies. Could expand on error handling or performance implications.

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?

The description is well-structured into three paragraphs: function, dependencies, usage. It is front-loaded with the core action. Slightly verbose but each sentence adds value.

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

Completeness4/5

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

Given 9 parameters all documented in schema, the description covers the output (accuracy ratio per target, mean) and real-AT fidelity caveat. It also mentions dependencies. Lacks output format details but is adequate for the complexity.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the 'strategy' parameter (linear vs. semantic) and noting 'maxTargets' default and trade-off. This goes beyond schema definitions.

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?

The description clearly states the tool validates Tactual's predicted navigation paths using a virtual screen reader, detailing the internal process and output. It distinguishes itself from siblings like analyze_url and trace_path by focusing on validation against predictions.

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?

It provides explicit guidance on when to use ('closing the modeled-vs-virtual loop') and advises using sparingly due to cost. It lacks direct mention of when not to use or alternatives, but the context is informative.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/tactual-dev/tactual'

If you have feedback or need assistance with the MCP directory API, please join our Discord server