A proposed MCP layer would expose a11y trees with low integration cost and no per-platform code; phoneshell's own tree reader is 170-plus lines of hand-written iOS-specific filtering rules

A July 2026 paper scores a proposed Model Context Protocol accessibility layer "Low" integration cost against "High" for the per-framework tree scraping every current GUI agent does today, in its own comparison table. phoneshell's perception/tree.py is that second column made concrete: rules written specifically for how Apple's XCUITest reports iOS UI, because a raw dump is 3000-plus nodes and 400KB of JSON per screen. No implementation of the proposal exists yet to compare it against.

MCP-Driven Accessibility Tree Standardization for AI-Powered Screen Reader Agents (arXiv:2608.24898, Ramineni, Saksena, Agarwal, Bidkar, Pothineni, Maruthavanan, Butra, Chintham, submitted 13 July 2026) proposes using the Model Context Protocol, the same wire format Anthropic's Claude and other tool-calling agents use to reach external systems, as a shared transport between platform accessibility APIs and LLM-based agents. Today, the paper argues, four separate frameworks, Windows UI Automation, macOS Accessibility, Android AccessibilityService and web ARIA, each need their own integration code, and a screenshot alone "lacks the semantic roles and relationships screen readers need." Its own Table I scores three perception strategies on four axes, and the comparison is stark: screenshot and vision gets Low semantic fidelity and High token cost; per-framework tree scraping gets High fidelity but High integration cost; the proposed MCP-mediated tree claims High fidelity at Low integration cost and Low-to-Medium token cost. The paper is explicit that this is a conceptual framework: "it does not present an empirical implementation."

What the proposal actually specifies

The paper's design is small enough to state in full. Three MCP resources expose the tree and a user's accessibility profile: a11y://tree/{session} for the full node graph, a scoped variant with root and depth query parameters for a subtree, and a11y://profile/{userId} for a persisted disability profile covering preferred reading granularity, landmark verbosity, minimum interactable element size, and preferred confirmation behavior before destructive actions. Four MCP tools act on it: focus(nodeId) moves accessibility focus, activate(nodeId) invokes a control's default action, read(nodeId, granularity) returns text at word, sentence or block granularity, and query(predicate) searches by role or name pattern. A node carries a stable identifier, an ARIA-aligned role, an accessible name, a state set such as focused or disabled, a bounding-region hint, and an ordered list of child identifiers. Tree-change events are pushed rather than polled. None of this has a reference implementation; the paper's own contribution is "comparative analysis of accessibility APIs, GUI agent architectures, and the MCP specification," not code.

Source: arXiv:2608.24898, Table I, read 29 October 2026. The MCP-mediated row is the paper's own conceptual proposal, with no measured implementation behind the scores.

What phoneshell's own tree reader actually does instead

phoneshell has never had the option this paper proposes, so it built the per-framework side of the comparison by hand. phoneshell/perception/tree.py states the problem it exists to solve in its own opening lines: "a raw /source dump for a screen like GrabFood is 3000+ nodes and 400KB of JSON: unusable as a prompt and full of layout scaffolding with no meaning." Its fix is a set of rules "learned from how XCUITest actually reports iOS UI," specific enough to name the quirks: node rects arrive already in screen points, but isVisible is computed by XCTest hit-testing in a way that marks real offscreen scroll content as visible anyway, so the file clips against the window rect itself rather than trusting the flag; container elements of type Other repeat a child's label, so an unfiltered tree hands a model five identical "Add to cart" candidates at the same coordinates; and a table row (Cell) gets its static text folded into one line while any real button inside it stays separate, because that is the unit a person actually perceives as one row. None of this logic is reusable against Android's AccessibilityService or a web page's DOM. It is specific to one framework, on one OS, which is precisely the "High integration cost" cell in the paper's own table.

What it means for a harness that already pays the cost the paper describes

• phoneshell is a working example of the exact cost the paper's table assigns the number "High": a dedicated file, with comments explaining specific iOS quirks, that a port to Android or web would not reuse at all. The paper's claim that an MCP layer reduces this to "Low" is plausible in principle but untested; nothing in the paper measures an actual integration against a real framework the way phoneshell's own file had to.
• The paper's proposed node fields, a stable identifier, an ARIA-aligned role, a state set, a bounding-region hint, map closely onto what phoneshell's own Element type already carries from WebDriverAgent. The gap is not in what gets exposed, it is in who writes the adapter: today that is phoneshell's own maintainers, reading XCUITest's specific behavior by trial; the paper's proposal would move that work to whoever builds the MCP server once, for every agent that speaks MCP.
• The paper's three research questions, protocol extensibility, the latency and fidelity trade-off against screenshots, and profile persistence, are all open. phoneshell's own measured numbers on the second question (hybrid tree-plus-image beating either channel alone, cited elsewhere on this site) are closer to actual evidence than anything in this paper, because phoneshell runs on a real device and this proposal does not run anywhere yet.

Check it yourself

# the exact problem phoneshell's tree reader exists to solve, in its own words
sed -n '1,16p' phoneshell/perception/tree.py

# the three element-type sets that encode iOS-specific filtering rules
grep -n "^INTERACTIVE\|^INFORMATIONAL\|^CONTAINERS" -A4 phoneshell/perception/tree.py

# confirm there is no MCP accessibility server anywhere in this repo
grep -rln "a11y://" --include="*.py" . || echo "no match"

# the paper's own comparison table and schema, read from the source
curl -s https://arxiv.org/html/2608.24898v1 | grep -iE "Table I|integration cost|a11y://"

What would prove this wrong

We claim this paper proposes an MCP accessibility layer with no reference implementation, scored against per-framework scraping using the paper's own, unmeasured table. That is wrong if a later version of the paper, or a separate project, ships and benchmarks an actual MCP accessibility server against real per-framework code; we would then want the paper's "Low integration cost" claim tested against a real port, not just asserted. We also claim phoneshell's own tree reader is iOS-specific enough that none of its filtering rules would transfer to another platform's accessibility API unmodified. That claim is falsified by anyone who takes perception/tree.py and successfully points it at Android's AccessibilityService or a browser's DOM with no changes to the rule sets we quoted above. We will treat either event as grounds to revisit this piece by 30 April 2027.