bad-ass-mcp

Overview Schema Source Related Servers Discussions Admin

get_tree

Retrieves a window's accessibility tree as compact JSON, pruning nameless wrappers while preserving named and interactive nodes so you can inspect UI structure without screenshots.

Instructions

Return the accessibility tree for a window as a compact JSON string. Use list_windows() first to get a window_id.

Empty, nameless layout wrappers are pruned automatically, so the tree stays compact even on content-heavy pages while every named or interactive node is preserved. Very large pages are additionally capped to a byte budget so the result always fits the client: when that happens the root object carries "truncated": true and "dropped_nodes" (a count). To see the cut content, pass max_depth to cap recursion depth, or use find_elements() to target specific controls.

max_depth counts the nameless wrappers that pruning hides, and web content (WebView2, WKWebView, Chromium) sits under several of them: a cap below ~12 can stop above a page's content. A node whose children the cap skipped carries "truncated_by_depth": true, so an empty "children" there means "not walked", not "empty". Right after a Tauri/WebView2 window appears its web pane may not exist yet; wait_for_element on a control you expect is the reliable way to know the page has loaded.

Returned as a compact JSON string (not a nested object) so the client's result-size cap counts real content, not indentation whitespace; parse it with a JSON loader.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "window_id": "<window_id>"
    },
    "name": "get_tree"
  }
}

Input Schema

Name	Required	Description	Default
`max_depth`	No
`window_id`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 13, 2026

TDQS

A4.7/5.0

Behavior4/5

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

No annotations are supplied, so the description carries the full burden, and it does an unusually good job: it discloses automatic pruning of nameless wrappers, byte-budget capping with 'truncated': true and 'dropped_nodes', depth-cap side effects via 'truncated_by_depth', and the fact that an empty 'children' may mean 'not walked'. The only gap is that it does not state permission or read-only/safety characteristics, which for a read tool is a minor omission.

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?

Front-loaded with the core purpose and prerequisite, then organized into pruning, truncation, depth, and format concerns. It is long but nearly every sentence carries operational detail; the closing paragraph partly restates 'compact JSON string' from the first sentence, which is the main redundancy.

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 an output schema exists, the description need not document return values, yet it usefully explains the truncation flags an agent must interpret. Depth-counting semantics, load-timing caveats, and the JSON-string parsing requirement make it complete for correct invocation.

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?

Schema description coverage is 0%, so the description must compensate, and it does: max_depth is explained as counting nameless wrappers that pruning hides, with a concrete hint that a cap below ~12 can stop above web content; window_id is tied to list_windows(). This adds real meaning the schema does not carry.

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?

Opens with a specific verb and resource: 'Return the accessibility tree for a window as a compact JSON string.' It distinguishes itself from siblings by naming list_windows() as the prerequisite and find_elements() as the alternative for targeted lookup.

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?

Gives an explicit prerequisite ('Use list_windows() first to get a window_id'), explicitly routes to alternatives ('use find_elements() to target specific controls', 'wait_for_element on a control you expect is the reliable way to know the page has loaded'), and warns about the WebView2 pane-not-yet-existing case. When-to-use and when-to-use-something-else are both covered.

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

Deploy Server