nvda-mcp server

Overview Schema Source Related Servers Discussions Admin

Look up NVDA's Python API (for developers)

nvda_lookup_api

Read-onlyIdempotent

Check whether an NVDA API name exists in the running version, see its signature, docs and deprecation status, or search loaded modules before writing add-on code.

Instructions

For add-on developers: check a name in the Python code of the NVDA that is running, before writing add-on code that uses it. NVDA changes its API in the first release of each year, so names remembered from older versions may be gone, renamed or deprecated.

With name: whether it exists, what it is, its signature, docstring and members, where it is defined (with a link to NVDA's source for this release), and whether it looks deprecated; close names when it does not exist. With search: names containing the text in the loaded modules of NVDA and its add-ons, and in the classes they define. It reads only, and does not run the code it looks at.

Input Schema

Name	Required	Description	Default
`name`	No	A dotted name to look up, such as 'controlTypes.Role.TOGGLEBUTTON', 'eventHandler.requestEvents' or 'NVDAObjects.NVDAObject'.
`limit`	No	With search: show at most this many names.
`search`	No	Instead, part of a name to find in the modules of NVDA and its add-ons, such as 'requestEvents' or 'liveRegion'.
`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.5/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, but the description adds genuinely new behavior: the full return payload (existence, kind, signature, docstring, members, definition location with source link, deprecation suspicion, close-name suggestions on failure) and the safety clarification that it 'does not run the code it looks at'. That last point is a real disclosure beyond the annotations; minor redundancy with readOnlyHint keeps it from a 5.

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?

Front-loads the audience and the action, then uses a parallel 'With name / With search' structure that maps cleanly onto the two modes. The motivation sentence about annual API churn earns its place by explaining why the tool exists; nothing is padding.

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?

All four parameters have zero required entries, the mutually exclusive modes are explained, and an output schema exists so return-format detail is not strictly needed (the extra summary of returned fields is a bonus). Nothing an agent needs to choose and call this tool correctly is missing.

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 the baseline is 3, but the description adds the governing semantics the schema only implies: 'With name...' versus 'With search...' as alternative modes with distinct result shapes. The limit and response_format parameters are left to their schema descriptions, which already cover them.

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: look up a name in the Python code of the running NVDA instance, targeted at add-on developers. It also distinguishes from sibling runtime tools by scope ('the Python code of the NVDA that is running' plus add-on modules) and by the two lookup modes.

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 clear trigger ('before writing add-on code that uses it') and explains why it matters (API breaks in the first release of each year). It also implicitly routes between the name mode and the search mode. It does not explicitly exclude the neighbouring tools such as nvda_inspect_object or nvda_list_scripts, which is the remaining gap.

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