Skip to main content
Glama
fixed-width

glass

by fixed-width
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust

glass_a11y_snapshot

Read-only

Capture the active window's semantic UI as a compact accessibility tree with roles, names, bounds, and states. Use as a low-token element map; for exact value or transition checks, use the wait tool.

Instructions

Capture the active window's current semantic state as a compact accessibility tree (role, name, description, bounded editable value, window-relative bounds and states). This is one observation, not proof of transition completion or visual appearance. For exact runtime verification, call glass_wait_for_element with the element's name, description and/or role, plus value for an exact editable value (value_contains for a substring). The compact value may be unavailable, redacted or truncated; use that wait rather than repeated snapshots when the full queryable value matters. Rendered as compact text — deterministic, low-token element addressing alongside screenshots. Each line is #<id> <Role> "<name>" desc="<description>" (x,y wxh) [states]. desc carries a second label the platform exposes apart from the name, and appears only where one exists and differs from the name; glass_wait_for_element and glass_scroll_to_element can select it with the description parameter. Pass an #id to glass_click_element. Errors if the backend or app exposes no accessibility tree (e.g. a canvas/black-box app) — fall back to glass_screenshot then. Web content arrives under a Document element, and a childless Document is disclosed in its own notice: take a fresh snapshot first, then pixels. A placeholder the app published for content it has not exposed gets its own notice — only pixels reach it. Optional max_nodes: raise the element cap, or 0 to remove the element-count limit (default caps protect the token budget).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
max_nodesNoMaximum number of elements to include. Omit for the default cap (protects the token budget). Pass a larger number to raise it, or `0` for the full tree (no limit). A snapshot renumbers ids, so re-read them after changing this.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.2.0
    • addedInput schema / $schema
      Added value: +"https://json-schema.org/draft/2020-12/schema"
    • addedInput schema / properties / max_nodes
      Added value: +{
+  "description": "Maximum number of elements to include. Omit for the default cap (protects the token\nbudget). Pass a larger number to raise it, or `0` for the full tree (no limit). A\nsnapshot renumbers ids, so re-read them after changing this.",
+  "format": "uint32",
+  "minimum": 0,
+  "type": [
+    "integer",
+    "null"
+  ]
+}
  2. Addedv1.0.3

TDQS

A4.6/5.0
Behavior5/5

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

The annotations only provide readOnlyHint=true; the description goes far beyond that by disclosing the compact-text line format, stable id-based addressing, redaction/truncation of the compact value, error behavior when no accessibility tree exists, the Document wrapper for web content, placeholder notices, and the max_nodes token-budget cap. There is no contradiction with the annotations, and the extra behavior detail is exactly what an agent needs to interpret results safely.

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 long but front-loaded with the core purpose and each sentence carries a distinct operational fact: output format, sibling routing, value redaction, error fallback, Document behavior, placeholder noticess, and cap behavior. It could be improved with structured bullets or shorter sections, but no sentence is filler for a tool this behaviorally rich.

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?

No output schema exists, so the description correctly carries the burden of explaining return values; it gives the exact line grammar `#<id> <Role> "<name>" desc="<description>" (x,y wxh) [states]` and explains how desc, ids, and states are used. It also covers error cases, web-content structure, placeholder notices, the single optional parameter, and explicit fallback tools, making the definition complete for a one-optional-param read-only tool.

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%, and the schema already fully documents max_nodes: omit for default cap, pass a larger number to raise it, pass 0 for no limit, and re-read ids because snapshots renumber them. The description's max_nodes sentence mostly paraphrases the schema ('raise the element cap', '0 to remove the element-count limit', 'default caps protect the token budget'), so it adds no material new parameter meaning beyond the schema. The baseline of 3 for high schema coverage 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 opens with a specific action and resource: 'Capture the active window's current semantic state as a compact accessibility tree' and enumerates exactly what the tree contains (role, name, description, bounded editable value, window-relative bounds, and states). It also distinguishes itself from glass_wait_for_element and glass_screenshot by explicitly labeling itself as one observation, not proof of transition completion or visual appearance.

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?

The description gives explicit when-to-use and when-not-to-use guidance: call glass_wait_for_element for exact runtime verification, use value/value_contains for editable values, and prefer the wait over repeated snapshots when the full queryable value matters. It also names concrete fallback paths, such as using glass_screenshot when no accessibility tree exists and taking a fresh snapshot before pixels for a childless Document.

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