A
licenseNot graded
qualityB
maintenanceA Python-based MCP server for local Windows diagnostics, task management, cleanup, hardware inspection, security checks, and administrative workflows.
4
MIT
DeviceLens MCP
by Dark-Hunt3r1
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@DeviceLens MCPList my connected physical devices."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
DeviceLens MCP
DeviceLens is a local, detection-first Windows MCP server that turns Device Manager's flattened records into understandable physical-device groups. Its inventory and update workflows are read-only. It can open the exact Windows Properties dialog for an interface, but it never disables, enables, removes, updates, or installs a device or driver.
Instead of presenting twenty generic entries such as HID-compliant device, DeviceLens uses Windows device containers to show which interfaces belong to the same keyboard, mouse, headset, controller, monitor, or other peripheral.
Current milestone
Version 0.6.0 implements the Device Explainer, update-audit foundation, exact Properties-dialog inspection, and guarded user-operated interface identification:
Numbers physical device groups as
D01,D02, and so on.Numbers child interfaces as
D01.1,D01.2, and so on.Groups interfaces using Windows' real PnP container identity.
Explains common generic names such as consumer controls, system controls, vendor-defined HID channels, and the misleading barcode-reader classification.
Separates connected devices from disconnected history.
Shows the installed driver version for a representative parent interface.
Captures the complete PnP driver inventory, including internal adapters that are not useful peripheral containers.
Saves schema-2 snapshots and compares installed driver version, INF, and provider changes.
Searches Windows Update for currently applicable driver offers without downloading them.
Searches Microsoft Update Catalog with a broadened discovery query, then accepts a package only when one of Windows' full local hardware or compatible IDs exactly matches a package ID. Revision-specific IDs remain distinct.
Separately searches Windows Update for pending Windows, .NET, and security software updates without downloading or installing them.
Can open the Windows Properties dialog for one exact
D03.2-style interface without clicking or changing anything.Can assess whether a user-operated identification test is appropriate for one exact
D03.2-style interface.Leaves every Disable Device and Enable Device action to the user in Windows; DeviceLens contains no device-state command.
Never installs, downloads, disables, enables, removes, restarts, or updates a Windows device or driver, and never changes firmware, BIOS, or the driver store.
Snapshot capture writes JSON only under %LOCALAPPDATA%\DeviceLensMCP\snapshots by default. Set DEVICELENS_DATA_DIR to use another location.
Related MCP server: Audit Bridge MCP
Example
DEVICE D03 — Ducky One X Wireless
Current state:
State: CONNECTED
Kind: physical
Physical identity: 3233:0016
Windows interfaces: 12
Interfaces:
D03.1 [ACTIVE] HID Keyboard Device
A keyboard-capable interface. Multifunction peripherals can expose one even when the whole product is not just a keyboard.
D03.2 [ACTIVE] HID-compliant bar code badge reader
Windows classified this HID usage as scanner-style input. On multifunction keyboards or controllers it can be an auxiliary interface; it does not prove a physical barcode reader exists.
D03.3 [ACTIVE] HID-compliant consumer control device
A media/consumer-control interface, commonly used for volume, playback, headset, or extra-device buttons.The D numbers are positions in the most recently displayed report. DeviceLens remembers exactly which stable container each number referred to. If the inventory changes between listing and explaining, it follows that identity. If the device vanishes from current Windows inventory, DeviceLens returns its cached last-report record as ABSENT SINCE LAST REPORT; it never silently reuses D01 for different hardware. The hidden container ID and hardware fingerprint remain the long-term comparison identities.
Requirements
Windows 11 with a recent
pnputilthat supports/enum-containersand XML output.Python 3.11 or newer.
No administrator rights for inventory, explanation, snapshots, or update research.
DeviceLens itself does not require administrator rights. Windows may require the user to approve a manual Device Manager action.
No API key or account.
A network connection is used only by the two explicit update-check tools.
Windows 10 fallback collection is planned but is not part of this first milestone.
Install for development
cd C:\path\to\device-lens-mcp
py -3.11 -m venv .venv
.\.venv\Scripts\python.exe -m pip install -e ".[dev]"Run the server over stdio:
.\.venv\Scripts\python.exe -m device_lens_mcpConfigure Codex
Add this to ~/.codex/config.toml:
[mcp_servers.device_lens]
command = "C:\\path\\to\\device-lens-mcp\\.venv\\Scripts\\python.exe"
args = ["-m", "device_lens_mcp"]
cwd = "C:\\path\\to\\device-lens-mcp"
enabled = true
default_tools_approval_mode = "writes"
startup_timeout_sec = 20
tool_timeout_sec = 180
[mcp_servers.device_lens.env]
DEVICELENS_OFFICIAL_REPOSITORY = "Dark-Hunt3r1/device-lens-mcp"Restart Codex after saving, then use /mcp to verify that device_lens is connected.
Beginner walkthrough: identify an ambiguous interface
DeviceLens is an explanation and detection tool, not a one-click driver updater. Read the exact interface information before interacting with Device Manager.
Call
devicelens_list_devicesand choose the physical device group you are investigating.Call
devicelens_explain_devicefor that group. Do not rely on a generic label such asHID-compliant deviceby itself.Prefer the read-only method first: capture a snapshot, physically unplug or switch off the suspected peripheral, capture another snapshot, and compare them. The removed interface IDs usually identify the relationship without disabling anything.
If unplugging is impractical, call
devicelens_prepare_identification_testfor one exact interface such asD03.2. Stop if DeviceLens marks it ineligible.Before a manual test, make sure you know how to re-enable a device and have another working input method. DeviceLens blocks descriptions and classes associated with keyboards, mice, touchpads, trackpads, trackballs, pointing devices, touchscreens, displays, network adapters, storage devices, controllers, hubs, firmware, and system devices.
Call
devicelens_open_device_propertiesfor the exact eligible interface. DeviceLens opens that instance's Properties dialog and does nothing else.If needed, verify Properties > Details > Device instance path against the exact instance ID reported by DeviceLens. Do not identify duplicate entries only by their position in the list.
Copy the exact recovery command returned by DeviceLens before disabling anything. It has the form
pnputil /enable-device "EXACT_INSTANCE_ID"and must be run by the user from an Administrator terminal if normal Device Manager recovery is unavailable.The user may choose Disable Device manually, observe what stops working for no longer than about one minute, and then manually choose Enable Device for that same instance. DeviceLens and the model must not click either control.
If Windows refuses the action, stop. Do not use
/force, another administrative tool, or a different selector to bypass the refusal. Return to snapshot comparison, physical unplug/replug testing, screenshots, and read-only metadata.
There is no guaranteed automatic restoration. The user remains responsible for re-enabling anything they manually disable. If that recovery step is not understood and available before the test begins, do not perform the test.
If a mouse was disabled accidentally
DeviceLens will not approve a mouse or pointing-device interface for a manual test, but recovery should still be understood before opening Device Manager:
If the exact Properties dialog remains open, use the keyboard to move through its controls and select Enable Device.
Otherwise, connect a second USB mouse, use a touchpad or touchscreen, or use the keyboard to open an Administrator terminal and run the exact recovery command that was copied before the test.
The recovery command enables only the exact recorded device instance and contains no
/forceoption.Do not rely on restarting Windows. A device manually disabled in Device Manager may remain disabled after restart.
If there is no alternate input method and the user cannot operate an Administrator terminal with the keyboard, the test must not begin.
Tools
devicelens_get_capabilities
Reports the platform, safety boundary, and recommended workflow.
devicelens_list_devices
Returns a structured inventory and a clean text report. Set include_disconnected=false to show only current devices.
devicelens_explain_device
Accepts a report number such as D03, a container ID, a stable ID, or an unambiguous device name. Returns numbered interfaces, plain-language explanations, an assessment, a recommendation, and representative installed-driver metadata.
devicelens_open_device_properties
UI-only. Accepts one exact interface number such as D03.2, resolves and verifies its full Windows instance ID, and opens that instance's Windows Properties dialog using the documented Device Manager entry point. The tool does not click any button, change a setting, require administrator access, or authorize a later action. A model may inspect the dialog, but it must obtain a new explicit request before clicking Disable, Uninstall, Update Driver, Roll Back Driver, or any other modifying control.
devicelens_prepare_identification_test
Read-only. Accepts one exact interface number such as D03.2 and reports whether a user-operated identification test is appropriate. Parent devices, internal buses, primary keyboard/mouse classes, storage, display, network, firmware, system, controller, adapter, and hub-level entries are excluded. DeviceLens performs no device-state action; the user must manually perform and reverse any Device Manager action.
devicelens_capture_snapshot
Writes a local JSON snapshot without changing Windows. This is intentionally not annotated as protocol-level read-only because it creates a file.
devicelens_list_snapshots
Lists locally saved DeviceLens snapshots.
devicelens_compare_snapshots
Compares two snapshots or a saved snapshot against current. Reports added, removed, changed, and re-enumerated device groups plus installed driver version, INF, and provider changes. Version-1 snapshots remain readable, but DeviceLens warns that they do not contain driver inventory.
devicelens_check_driver_updates
Performs a read-only online search. It queries the configured Windows Update service once for applicable, not-installed driver offers. It also searches Microsoft Update Catalog for connected third-party packages, verifies the exact hardware ID in package details, filters for this machine's architecture and Windows 11 products, and compares numeric version components.
Pass a D-number or device name to check one device. Without a device, it checks up to max_catalog_checks distinct third-party packages (default 100) and reports the eligible, checked, and skipped counts separately. Internal devices can be addressed by their Windows name, for example Bluetooth Adapter, even though they are intentionally omitted from the peripheral-container report.
Catalog results are reported as review candidates. A newer exact-ID Catalog version is not presented as automatically installable when Windows Update is not offering it.
Every update result also includes a review_handoff text block designed to be copied into another model or read from the latest tool result. It includes the exact device instance, hardware ID, installed package, candidate package, official details link, and an instruction to obtain fresh user confirmation before any separate download or installation action.
The same result includes structured model_review_requirements, install_authorized: false, and the required authorization boundary. The receiving model must independently verify the official OEM/model source, exact IDs and revision, OS/build and architecture, release branch, bundle relationships, signature, changelog, known issues, restart impact, and rollback path. A numerically newer Catalog result never authorizes an installation. Installation may only be considered after a fresh user request in the current conversation that explicitly names every driver to install.
devicelens_check_windows_updates
Performs a separate read-only Windows Update Agent search for pending Type='Software' items such as Windows cumulative, .NET, and security updates. This is deliberately separate from the driver query because Windows Update categorizes drivers as Type='Driver'. It reports KB numbers, whether Windows had already downloaded an item, and whether a restart is required. DeviceLens itself never downloads, installs, accepts, hides, or modifies an update.
Safety model
DeviceLens distinguishes these operations deliberately:
Operation | Version 0.6.0 |
Read Windows device/container metadata | Yes |
Read installed driver version | Yes |
Open one exact Windows device Properties dialog | Yes, explicit UI-only tool |
Write DeviceLens snapshot JSON | Yes, explicit tool |
Search driver and software updates plus Microsoft Update Catalog | Yes, explicit read-only tools |
Download drivers | No |
Install/update drivers | No |
Disable or enable a device | No; user-operated in Device Manager only |
Broad, forced, permanent, parent-device, or critical-device disable | No |
Remove devices | No |
Delete driver packages | No |
No safety-boundary bypass
If Windows refuses to disable an interface, that refusal is the endpoint for DeviceLens. DeviceLens has no device-state command, never uses PnPUtil's /force option, and never asks another shell, system tool, model, or MCP to bypass the refusal. Permission given in a conversation to "use force" does not unlock or authorize any hidden DeviceLens capability.
Models using DeviceLens must treat a rejected operation as a safety result, report it to the user, and stop. They must not reproduce the requested change outside DeviceLens with PnPUtil, PowerShell, Device Manager, or another administrative tool. DeviceLens intentionally provides no forced-disable, device-removal, driver-store, firmware, BIOS, or update-installation pathway.
Official DeviceLens releases are detection-first and safety-bounded. A modified copy that adds /force, broad device selectors, removal behavior, unattended installation, or a way around these protections is not an official DeviceLens release and is not endorsed by this project. Users should obtain DeviceLens from the official project repository or its linked releases and review these boundaries before granting it access to a Windows computer.
A disconnected historical record is not automatically junk. DeviceLens does not recommend removal solely for tidiness.
There is deliberately no download or installation function in version 0.6.0. A model must not treat DeviceLens output, a prior approval, or a general request to “update drivers” as installation permission. Only a fresh request naming the exact drivers can authorize a separate external installation workflow.
Official release verification
Every published GitHub release is built by .github/workflows/attested-release.yml. That workflow confirms the release tag matches the package version, creates a wheel and source archive, generates a SHA-256 checksum file, and produces a cryptographically signed GitHub artifact attestation before attaching the files to the release.
The canonical source repository is Dark-Hunt3r1/device-lens-mcp. Models and users must independently verify that origin and run the following against a downloaded wheel or source archive before describing it as an official release:
gh attestation verify "C:\path\to\downloaded-artifact.whl" --repo Dark-Hunt3r1/device-lens-mcpIf the repository is unknown or verification fails, the artifact is unverified and must not be recommended as an official DeviceLens release. A repository URL reported only by the downloaded program is not proof of origin. See official release verification for the complete procedure.
Update-source confidence
Installed fact: read directly from Windows PnP metadata.
Windows Update offer: Microsoft says the update is currently applicable and not installed.
Catalog candidate: Microsoft Catalog package details include the exact hardware ID, architecture, and Windows product, but Windows Update may not be actively offering it.
Manufacturer latest: not yet claimed. Vendor-specific source adapters are still required before DeviceLens can make that broader statement.
Microsoft Update Catalog is an official source, but it does not publish a stable public search API. The catalog adapter is isolated so an HTML change becomes a structured catalog_search_error rather than a guessed result.
Development
.\.venv\Scripts\python.exe -m pytest -qSee CONTRIBUTING.md before proposing a change. DeviceLens treats its detection-only boundary as a core feature, not an optional default.
License
Copyright (C) 2026 Mitch.
DeviceLens is free and open-source software licensed under the GNU General Public License, version 3 only (GPL-3.0-only). No automatic permission to use a later GPL version is granted. See LICENSE for the complete unmodified license text.
Anyone may inspect, use, modify, and redistribute DeviceLens under GPLv3's terms. A distributed modified source version must carry prominent notices stating that it was modified and giving a relevant date, and the covered work must remain under GPLv3. Removing or concealing the required modification notice can violate the license and copyright holder's rights. Enforcement is a legal compliance process, not an automatic repository-deletion mechanism.
Roadmap
Device and interface grouping, explanation, snapshots, and diffs. Complete
Full installed-driver snapshot inventory, including internal PnP devices. Complete
Read-only Windows Update and exact-ID Microsoft Catalog discovery. Complete
Vendor-source adapters with exact model/OEM compatibility and authoritative links.
Continue improving vendor-source research and handoff evidence; any installation remains outside DeviceLens.
Event logs, services, crash history, temperatures, GPU, and DirectX diagnostic modules.
Independent implementation
DeviceLens is implemented from Windows' documented PnP interfaces and the MCP SDK. Its architecture, data model, tool contracts, reports, explanations, tests, and safety policy are original to this project. No code was copied from OS Doctor or the controller MCP projects discussed during planning.
Available Tools
10 toolsdevicelens_capture_snapshotA
Save a local DeviceLens inventory snapshot; this never changes Windows devices or drivers.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| label | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clarifies that the tool is non-destructive to devices/drivers, which is valuable beyond annotations (destructiveHint false). However, it omits potential side effects like disk usage from saving snapshots. Consistent with annotations, no contradiction.
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?
The description is a single, efficient sentence that front-loads the core purpose and safety note. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and an output schema (not shown). The description covers purpose and safety but lacks explanation of the label parameter and return value context. Adequate but not thorough.
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% for the single optional 'label' parameter. The description adds no meaning about its purpose, format, or effect. Baseline without schema coverage is 4, but the description fails to compensate, hence 2.
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 action ('Save a local DeviceLens inventory snapshot') and distinguishes it from sibling tools by emphasizing safety ('never changes Windows devices or drivers'). This provides a specific verb and resource with differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies safety but does not explicitly state when to use this tool versus alternatives like devicelens_list_snapshots or devicelens_check_driver_updates. No guidance on prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
devicelens_check_driver_updatesARead-onlyIdempotent
Search online for driver updates without downloading or installing anything.
With a device name or D-number, checks that device's third-party driver packages. Without a device, checks up to max_catalog_checks distinct connected third-party packages and reports exactly how many eligible packages were skipped by that limit.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| device | No | ||
| max_catalog_checks | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, etc. The description adds context about online searching without downloading/installing, and the limit behavior for skipped packages. No contradictions with annotations.
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?
The description is two concise paragraphs, front-loaded with the main action. Every sentence adds value, with no wasted words.
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 annotations and an output schema (not shown), the description provides enough context for usage. It covers the two modes and limit behavior. Could mention return format, but output schema likely covers it.
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 0%. The description partially explains the device parameter (by name/D-number) and the max_catalog_checks limit, but does not fully describe parameter syntax or defaults. Some meaning is added, but not enough to fully compensate.
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 searches for driver updates without downloading/installing, and differentiates two modes (with device vs. without). This distinguishes it from siblings like devicelens_check_windows_updates.
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?
The description explains when to use the tool and describes the two operational modes with the max_catalog_checks limit. However, it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
devicelens_check_windows_updatesARead-onlyIdempotent
Search for pending Windows, .NET, and security software updates without downloading or installing.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool does not download or install updates, which is crucial behavioral context not fully captured by annotations (readOnlyHint, idempotentHint, destructiveHint). This adds transparency beyond the structured fields.
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?
The description is a single, concise sentence that conveys the essential purpose and behavior without any extraneous information. Every word earns its place.
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 the tool has no parameters and an existing output schema, the description is sufficient. It clearly states the scope (Windows, .NET, security updates) and non-installation behavior, which is adequate for an AI agent to select and invoke the tool correctly.
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?
The tool has no parameters, so the input schema is empty. The description does not need to add parameter information. The baseline for 0 parameters is 4, which is appropriate.
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's function: searching for pending Windows, .NET, and security software updates. It explicitly mentions it does not download or install, which distinguishes it from update installation tools. The sibling includes devicelens_check_driver_updates, indicating a clear differentiation between OS/security updates and driver updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly provide usage guidelines or alternatives. It implies the tool is for checking updates without installing, but there is no guidance on when to use this versus other tools like devicelens_check_driver_updates. However, the sibling names offer implicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
devicelens_compare_snapshotsARead-onlyIdempotent
Compare two saved inventories, or compare a saved snapshot with the current live device state.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | current | |
| before | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds context about comparing two specific snapshots or a snapshot with current state, which is useful behavioral detail beyond the annotations.
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?
The description is a single sentence that is concise, front-loaded with the verb, and contains no superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 2 parameters, required fields, and an output schema, the description is somewhat incomplete. It does not explain parameter defaults or format, but the core functionality is clear for a simple comparison tool.
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%, so the description must compensate. It only implicitly suggests that 'before' and 'after' are snapshot identifiers, but does not explain that 'after' defaults to 'current' or the format of the identifiers.
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 verb 'compare' and the resources 'saved inventories' and 'current live device state'. It distinguishes from sibling tools like devicelens_capture_snapshot and devicelens_list_snapshots.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives, no prerequisites, and no exclusions or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
devicelens_explain_deviceBRead-onlyIdempotent
Explain one grouped device and number its Windows child interfaces (for example, D03.1).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| device | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
B3.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, which are consistent with the description's 'explain' action. The description adds that child interfaces are numbered with an example format, providing useful additional context.
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 a single sentence that front-loads the action and includes an example. It is concise and avoids unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists but is not shown; the description does not clarify what the tool returns. For a simple read tool with one parameter, the description is adequate but could be more complete regarding output.
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%. The description does not explain the 'device' parameter's expected format (e.g., ID or name), leaving the agent without guidance on what to pass.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'explain' and the resource 'grouped device', and mentions numbering child interfaces with an example. It distinguishes from sibling tools like list_devices and open_device_properties by indicating a different action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. Sibling tools exist but no exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
devicelens_get_capabilitiesARead-onlyIdempotent
Describe DeviceLens safety boundaries, platform requirements, and available workflows.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds context about what is described but does not disclose additional behavioral traits beyond annotations.
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?
Single sentence, front-loaded with key information, no unnecessary words.
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?
Given no parameters, rich annotations, and an output schema, the description provides sufficient context for the agent to understand the tool's purpose and usage.
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?
No parameters exist, so the description does not need to explain them; baseline score of 4 for 0 parameters is appropriate.
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 it describes safety boundaries, platform requirements, and available workflows, which is a specific verb-object pair distinct from sibling tools that capture snapshots, check updates, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives, though it is implied that it should be called initially to understand DeviceLens capabilities before using other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
devicelens_list_devicesBRead-onlyIdempotent
List Windows devices as numbered physical groups instead of flattened Device Manager interfaces.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| include_disconnected | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
B3.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds the unique formatting aspect but does not detail return behavior, default behavior (include_disconnected true), or any other operational traits beyond the basic listing.
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 a single sentence with no unnecessary words. It is front-loaded with the action, though it could benefit from slight expansion for parameter clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one optional parameter and an output schema, the description is brief but lacks explanation of the output format or usage context relative to siblings. It is minimally adequate but not comprehensive.
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%, and the description does not explain the one parameter 'include_disconnected'. While the parameter name is somewhat self-explanatory, the description should compensate for the missing schema docs but fails to do so.
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 lists Windows devices with a distinctive format ('numbered physical groups instead of flattened Device Manager interfaces'). This contrasts with sibling tools and provides a specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives like devicelens_capture_snapshot or devicelens_explain_device. No exclusions, prerequisites, or use cases are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
devicelens_list_snapshotsARead-onlyIdempotent
List DeviceLens snapshots previously saved in the local application-data folder.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds value by specifying the source as 'local application-data folder,' providing location context beyond the annotations. No contradictions.
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?
The description is a single, concise sentence with 9 words, front-loading the action and resource. No unnecessary information.
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 simple list tool with no parameters, annotated as read-only and idempotent, and with an output schema (implied), the description is complete. It covers the purpose and scope adequately.
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?
The tool has zero parameters, and schema description coverage is 100%. The description adds meaning by specifying what is listed (snapshots) and their location, which is sufficient for a parameterless tool.
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 explicitly states the verb 'List' and the resource 'DeviceLens snapshots previously saved in the local application-data folder.' It clearly distinguishes from sibling tools like devicelens_capture_snapshot (which creates) and devicelens_compare_snapshots (which compares).
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?
While the description does not explicitly state when to use it versus alternatives, the context of listing previously saved snapshots is clear. For a zero-parameter list tool, the usage is implicitly understood, but explicit guidance on when not to use (e.g., for capturing or comparing) is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
devicelens_open_device_propertiesA
Open Windows Properties for one exact interface without changing it.
Pass an interface number such as D03.2 from devicelens_explain_device, or a full device instance ID. This opens only the exact resolved Properties dialog. It never clicks Disable, Uninstall, Update Driver, Roll Back Driver, or changes any setting. Opening the dialog is not permission for a later modifying action.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| interface | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims the tool never changes any setting, yet the annotation readOnlyHint is false, indicating the operation may modify state. This contradiction reduces transparency. The description does add context beyond annotations (listing never-performed actions), but the contradiction is severe.
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?
The description is concise and well-structured, with a clear first sentence stating the core purpose, followed by essential usage details and behavioral caveats. No redundant words.
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?
Given the tool's simple functionality (opening a dialog) and the existence of an output schema, the description covers all necessary context: what it does, input requirements, limitations, and behavioral boundaries. It is complete without being verbose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining the 'interface' parameter format, providing examples ('D03.2'), and specifying its source (devicelens_explain_device). This adds clear, actionable meaning.
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 opens the Windows Properties dialog for a specific device interface without modifying anything. It uses specific verbs ('open', 'without changing') and differentiates from sibling tools like devicelens_explain_device by explicitly listing actions it does not perform.
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 input format (e.g., 'D03.2' from devicelens_explain_device or a full device instance ID) and clarifies that opening the dialog does not permit subsequent modifications. However, it does not directly contrast with siblings like devicelens_explain_device for when to use this vs. other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
devicelens_prepare_identification_testARead-onlyIdempotent
Assess a user-operated identification test for one exact numbered interface.
Pass an interface number such as D03.2 from devicelens_explain_device. The result states whether a manual test is appropriate and why risky devices are excluded. DeviceLens never disables or enables the device; the user must perform and reverse any Device Manager action themselves.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| interface | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds that DeviceLens never disables or enables the device and that the user must perform and reverse Device Manager actions themselves, providing safety context beyond annotations.
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 concise, consisting of four sentences that front-load the purpose. No superfluous information, though it could be slightly more structured (e.g., bullet points).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations covering safety and idempotency, and an existing output schema (not shown), the description provides adequate behavioral context. However, it does not explain the 'identification test' itself or error conditions, which may leave minor gaps for an AI agent.
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?
The input schema has 0% coverage (no parameter description). The description compensates by explaining the parameter is an interface number from devicelens_explain_device and gives an example (D03.2). This adds meaning but lacks detailed format constraints or allowed values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool assesses a user-operated identification test for one exact numbered interface, using a specific verb and resource. It mentions the output states whether a manual test is appropriate and why risky devices are excluded. While it doesn't explicitly differentiate from siblings, the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises passing an interface number from devicelens_explain_device, offering a clear source. However, it does not specify when to use this tool versus alternatives (e.g., when not to use it), nor does it mention any prerequisites beyond the interface number.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
A4/5.0
Disambiguation5/5
Each tool has a clearly distinct purpose, covering different aspects of device inventory and update checking without overlap.
Naming Consistency5/5
All tools use a consistent snake_case pattern with the 'devicelens_' prefix and verb_noun structure.
Tool Count5/5
With 10 tools, the server is well-scoped for its domain, neither too few nor too many.
Completeness4/5
The tool set covers the core workflows of inventory and update checking, though a delete_snapshot tool is missing for full lifecycle management.
Maintenance
ActivitySlowing
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
2,000+ MCP servers read at source level. Know what one does before you connect. Free, no key.
Read-only MCP server for turva.dev, an agent-readiness audit and advisory service.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
The MCP server that vets MCP servers: identity, risk grade and per-tool risk before you install.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceMCP server for orchestrating Windows system auditing tools, supporting system checks, configuration adjustments, and security operations via a standardized interface.
- AlicenseNot gradedqualityCmaintenanceAn MCP server for Windows process memory inspection/editing and crash dump analysis, enabling live memory scanning, patching, pointer resolution, disassembly, and offline dump examination via structured tool calls.MIT
- AlicenseAqualityCmaintenanceRead-only MCP server for diagnosing Windows crashes, stability, and gaming performance by reading event logs, crash dumps, hardware inventory, performance counters, and registry settings.35MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/Dark-Hunt3r1/device-lens-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server