Tactile's operating ladder has three rungs and the third one stops mid-word

The recommended entry point is a binary path inside the repository, documented for macOS

The document's first instruction is to prefer the macOS MCP, which lives at `mcps/tactile-macos-mcp` and is called the recommended entry point when available, on the grounds that it is faster and easier to use and exposes the accessibility-first workflow directly as MCP tools. The command it expects is a fixed path inside the checkout:

mcps/tactile-macos-mcp/bin/tactile-macos-mcp

So the primary entry point is a binary that lives in the tree rather than something you install from a package index or a release, and the repository has no tagged releases to fall back on. The version selection question is left to the agent: the skill prompt below tells it to choose the version for the corresponding operating system, which implies per-platform artifacts exist, yet only the macOS path is ever written down. No version list, checksum or signature accompanies it, so nothing in the repository lets you confirm which build you just ran.

Three ways in, and the third expects an OpenAI-shaped endpoint

There are three separate installation paths, and they cost different things. The first is the MCP binary above, which is local and needs no model configuration. The second is a skill, configured by handing the agent one sentence:

Configure this skill for me (make sure to choose the version for the corresponding operating system): https://github.com/yliust/Tactile

The third is direct API use, and it is where the environment variables appear: `TACTILE_OPENAI_BASE_URL`, `TACTILE_OPENAI_API_KEY` and `TACTILE_MODEL`, shown with literal placeholder values and a sample model of gpt-5.5. Two of the three names are tied to one vendor's shape, so the API mode assumes a base URL plus key plus model identifier rather than a plugin system, and the sample value tells you which model the author had in mind. Nothing states whether the MCP path also reaches a model, which leaves the boundary between a purely local operating layer and a client that bills per call unstated.

The operating ladder has three rungs and the third one stops mid-word

The method is a three-level ladder, written as prose rather than as anything the runtime enforces. Level 1 is accessibility semantics: read the tree, operate through element names, roles, states, hierarchy and actions, best for standard interface pieces such as buttons, text fields, menus, tables, dialogs and lists. Level 2 is OCR-grounded coordinates, where system OCR returns visible text together with its coordinates, making it a text-anchored fallback rather than a guess. Level 3 is the agent's own visual logic. Its description ends where the document does:

Level 1: Accessibility semantics
Level 2: OCR-grounded coordinates
Level 3: Native visual computer use
  Best for image-base

The one line that would say when level 3 applies, which is the line that tells an agent whether to give up on semantics, is cut off. The list of conditions that survives elsewhere in the text is longer than the rung: unavailable accessibility layer, OCR unable to locate the target, or a canvas-based, game-like, remote, image-heavy or semantically opaque interface.

Verification failure is redefined as missing feedback rather than a failed action

The verification section mirrors the ladder and then says something more careful than the ladder does. After each operation the agent should confirm the outcome, preferring accessibility state: whether a button became disabled, a checkbox became selected, a text field value changed, a dialog closed or a new list item appeared. OCR verification covers the cases where the visible text is the only signal, such as an expected error message, a success state or a page title. Screenshot understanding is the last fallback. What makes this section worth reading is the rule attached to failure: a verification failure does not always mean the action failed, it means the interface did not return enough reliable feedback, and the correct response is to retry, pick another path or drop to a more general visual method. The strategy explicitly declines to take over agent decisions, leaving the downgrade decision to context.

The gap list reads as the project's own accessibility audit

The document states its thesis as a question about interfaces that serve both humans and agents, then supplies a list of the ways software fails that test: buttons without readable names, incorrect control roles, dialogs invisible to the accessibility tree, state changes never exposed to assistive technologies, custom components visible only to sighted users, and incomplete keyboard and screen reader paths. Each of those is a case where level 1 of the ladder returns nothing useful, which makes the list a practical statement of when this project helps and when it quietly becomes level 2 or level 3 work with extra steps. The argument is also two-directional, that the easier software is to operate semantically, the more likely it is to be accessible to people. The paragraph carrying that point stops mid-sentence, in the middle of naming the users it affects most.

v0 begins as a skill, and the repository ships no package metadata

The version section says Tactile v0 will begin as a skill, and its goal is to package an operating method rather than a library, which sets the expectation that the artifact is instructions. The tree matches that: seven top level entries, README.md, README_zh.md, LICENSE, .gitignore, assets/, mcps/ and skills/, with no packaging file, no test directory and no CI configuration anywhere at the top, even though the project is recorded as Python. The MCP binary path and the skill directory are the deliverable, and everything else is documentation and media. Two other details sit awkwardly with that. The repository carries a LICENSE file at the root while its metadata records no license value, so the terms are readable in the file but absent from anything automated. And with no releases, there is no artifact to version-pin, only whatever is in the tree at the branch you cloned.

The demos are two hosted videos, and one of them was edited by an agent

Two demos are offered, a Lark and WeChat workflow and a CapCut video-editing workflow, and both are attached as GitHub user assets rather than kept in the repository, so nothing about them is versioned with the code. The CapCut entry carries a detail worth noting on its own: that demo video was edited by an agent using the Tactile skill to operate CapCut, which makes the demonstration self-referential in a way that is either a strong claim or a circular one depending on how much you trust it. What the document does not give, for either demo, is the input, the expected outcome, the failure case, or any measure of how many operations it took. The contrast case it argues against is at least written out as a loop, starting from a screenshot, inferring an element, predicting coordinates, clicking and inspecting again, which the text calls general but fragile.

Editorial conclusion

Treat it as a method to hand an agent rather than a library to depend on, because what ships is a skill definition, a macOS MCP binary path and two demo videos, with no package metadata, no tests and no release artifacts to pin. Before adopting it, check whether the applications you automate actually populate the accessibility tree, since the ladder's value collapses to nothing at level 3 for canvas-based or image-heavy interfaces, and read the model settings before using the API mode, which expects an OpenAI-shaped base URL and key.

Frequently asked questions

Official sources

1. Issues
2. README
3. yliust/Tactile on GitHub