nvda-mcp server

Overview Schema Source Related Servers Discussions Admin

Audit keyboard focus order

nvda_audit_focus_order

Destructive

Walk an application's keyboard focus order to report accessibility issues using NVDA announcements, flagging unlabeled, silent, duplicate, stuck, or escaping focus.

Instructions

Walk through an application's keyboard focus order and report accessibility problems, using what NVDA actually announces.

Starting from the current focus, this presses key repeatedly and records each control and what NVDA said. It stops when focus returns to the start, stops moving, or leaves the application. It flags unlabeled buttons, links and fields; controls NVDA says nothing for; duplicate names that users cannot tell apart; and focus that is stuck or escapes the app. Focus is left wherever the walk ends.

Ask the user to focus the first control of the window to audit before calling this. Needs key presses to be allowed, like nvda_press_keys.

Input Schema

Name	Required	Description	Default
`key`	No	The key that moves focus: 'tab' (default), 'shift+tab', 'downArrow'.	tab
`max_steps`	No	Press the key at most this many times.
`response_format`	No	'markdown' (default) is easier to read; 'json' keeps every field for further processing.	markdown

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.1.0Nov 5, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare non-read-only, non-idempotent, open-world and destructive behavior, and the description reinforces why: it presses a key repeatedly, enumerates the termination conditions (focus returns to start, stops moving, leaves the app), and warns that focus is left wherever the walk ends. That side-effect disclosure is the valuable addition; what remains unstated is whether the walk can be interrupted or undone.

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?

Front-loads the purpose, then the mechanism, then stopping rules and flagged issues, then prerequisites. Sizing is appropriate for a multi-behavior tool, though the list of flagged problem classes is long enough to be slightly dense.

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?

An output schema exists, so return values need not be described, and the description still covers prerequisites, stopping behavior and side effects. What is thin is the meaning of the 'key presses allowed' prerequisite and any guidance on what to do with the reported findings.

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

Parameters3/5

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

Schema coverage is 100%, with default, bounds and format guidance already on each parameter. The description only loosely echoes the key-pressing role of `key` and adds no syntax or format detail beyond the schema, so baseline 3 applies.

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?

States a specific verb and resource (walk keyboard focus order, report accessibility problems) plus the mechanism (what NVDA actually announces). This is clearly distinguishable from siblings like nvda_press_keys or nvda_get_object_tree, which do not audit or flag issues.

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 concrete pre-call condition (ask the user to focus the first control of the window to audit) and a capability prerequisite (key presses must be allowed, like nvda_press_keys). It does not explicitly say when to prefer this over alternatives such as nvda_list_elements or nvda_get_object_tree, so it falls short of full alternative routing.

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