Skip to main content
Glama
0xpolarzero

luda

by 0xpolarzero
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

desktop_inspect

Read-only

Inspect windows and locate controls by name, role, or state, returning a bounded accessibility tree with parent IDs and supported actions.

Instructions

Inspect a window or find controls by name/role substring and required states. Returns bounded tree, parent IDs, supported actions and 60-second element IDs. Owned browser text_fields have distinct provider-bound IDs for ordinary HTML fields; role="entry" filters for fields. Field metadata describes line breaks and write scope. When extra owned pages/windows or frames make the owned provider unavailable, native nodes remain independently inspected; owned_browser reports unavailable/code and text_fields is empty. Cached owned fields still refuse unsupported scope; no mutation fallback. Empty matches and unavailable accessibility are distinct.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo
roleNo
limitNo
statesNo
max_depthNo
window_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.3.4
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / max_depth
      Added value: +{
+  "default": 30,
+  "title": "Max Depth",
+  "type": "integer"
+}
    • addedInput schema / properties / name
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Name"
+}
    • addedInput schema / properties / role
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Role"
+}
    • addedInput schema / properties / states
      Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "States"
+}
  2. First observedv0.1.0

TDQS

A3.9/5.0
Behavior5/5

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

The description goes far beyond the readOnlyHint annotation, disclosing return contents, bounded tree/parent IDs/supported actions, 60-second element ID validity, provider-bound text field IDs, native fallback behavior, no mutation fallback, and the distinction between empty matches and inaccessible accessibility. This is rich behavioral context.

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

Conciseness3/5

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

The first sentence is front-loaded and clear, but the remainder is a dense, unstructured paragraph of conditional clauses about providers, caching, and edge cases. The content is informative but would benefit from bullet structure or clearer separation of concerns.

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?

Despite missing explicit parameter semantics, the description covers many important edge cases: provider unavailability, cached field behavior, role filtering for fields, and empty-versus-unavailable results. For a complex tool with no output schemaaine, it gives a solid high-level contract; the main gap is clarity around limit/max_depth/window_id usage.

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 explains role filtering and mentions required states, but does not clarify the meaning or allowed values of limit, max_depth, window_id, or states. Several parameters remain under-specified.

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-resource pair: 'Inspect a window or find controls by name/role substring and required states.' This clearly states what the tool does and distinguishes it from action-oriented siblings like desktop_click, desktop_type, or desktop_control.

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 gives useful contextual hints, such as role="entry" filtering for fields and behavior when the owned browser provider is unavailable, but it never explicitly says when to choose desktop_inspect over related tools like desktop_observe or desktop_control, nor when not to use it. Usage guidance is implied rather than stated.

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

Deploy Server

Other Tools