nvda-mcp server

Overview Schema Source Related Servers Discussions Admin

Press keys

nvda_press_keys

Destructive

Presses keys in the active window and reports what NVDA said plus where focus ended up, supporting keyboard-driven accessibility testing.

Instructions

Press keys in the active window, then report what NVDA said and where focus ended up.

This sends real input, so it can change or delete things in the user's application. Tell the user what you will press first. It fails with controlDisabled if the user has not allowed key presses, and with controlDenied if they declined; do not retry after controlDenied. To type text, nvda_type_text is faster and does not depend on the keyboard layout.

Input Schema

Name	Required	Description
`hold`	No	Modifiers to hold down while all the keys are pressed, then release. For example hold ['alt'] with keys ['tab', 'tab'] moves two places in the Alt+Tab switcher.
`keys`	Yes	Keys to press in order, using NVDA key names: 'tab', 'shift+tab', 'enter', 'space', 'escape', 'downArrow', 'control+home', 'alt+f4', 'f6', 'a'.
`record`	No	Also record what this action changed: how the accessibility tree around it changed (controls added, removed, renamed or moved, values and states) and the events NVDA handled. NVDA is silent for up to a few seconds while the tree is read. For something the user does, use nvda_trace_events with tree.
`settle_ms`	No	Stop listening once NVDA has been quiet this long.
`timeout_ms`	No	Stop listening, or waiting for until_speech, after this long in total.
`until_speech`	No	Keep listening until NVDA says something containing this text (ignoring case), such as 'sent' or a dialog title, instead of stopping at the first pause. The result says whether it was heard.
`record_within`	No	Record only inside this control, an id from nvda_find_objects, such as a chat's message list. Implies record. By default the web document or window around the action is recorded.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.1.0Nov 5, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true and openWorldHint=true, yet the description still adds substance: this 'sends real input, so it can change or delete things', it requires a user confirmation step, and it documents the two distinct failure codes (controlDisabled vs controlDenied) with different retry behavior. That error and consent semantics are not derivable from the annotations or schema.

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

Conciseness5/5

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

Four short sentences, each doing distinct work: capability, risk, confirmation protocol, error handling, and alternative. The risk warning is front-loaded immediately after the purpose, which is the right ordering for a destructive tool.

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

Completeness5/5

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

For a destructive, non-idempotent input-injection tool with 7 parameters, the description covers the safety profile, prerequisite consent, failure modes, and the main sibling alternative. An output schema exists, so return values need no further explanation.

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 description coverage is 100%, so every parameter (hold, keys, record, settle_ms, timeout_ms, until_speech, record_within) is already documented in the schema with examples and defaults. The description adds no parameter-level detail beyond implying the typing alternative, so the 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?

The description opens with a specific verb and scope: 'Press keys in the active window', and adds the observable outcome ('report what NVDA said and where focus ended up'). That framing lets an agent distinguish it from siblings like nvda_type_text, nvda_run_script, or nvda_activate_window without reading the schema.

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

Usage Guidelines5/5

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

It gives explicit when-to-use guidance ('Tell the user what you will press first'), names the alternative for text entry ('To type text, nvda_type_text is faster and does not depend on the keyboard layout'), and states a hard exclusion ('do not retry after controlDenied'). The record parameter also routes event-level tracing to nvda_trace_events, so the agent has a clear decision tree.

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