Skip to content

Releases: Ask-812/oswright

v0.8.2 - three bugs a Windows-only bench could not see

Choose a tag to compare

@Ask-812 Ask-812 released this 17 Sep 06:37

Fixes the first three external bug reports, all of which were real and all of
which were invisible from a Windows development machine.

The server was reporting the wrong version (#2). initialize announced
1.29.1 — the MCP SDK's version, not OSWright's — so no client could tell
which release it was talking to. FastMCP accepts no version argument and the
low-level server it wraps defaults to None, at which point the SDK reports
itself. The version now lives in a dependency-free oswright/_version.py and a
protocol-level test asserts what goes over the wire.

Cold OCR start no longer takes the server down (#1). On Linux and macOS the
OCR backend is EasyOCR, which imports Torch. Building it inside the first tool
call meant clients hit their request deadline, cancelled, and the stdio
transport was torn down mid-load — taking every OSWright tool out of the
session until restart. Measured here: 62.1 seconds, six times a typical
10-second client timeout.

The engine is now built by a daemon thread started at startup, with explicit
not_started / loading / ready / failed state and a remembered failure so
a broken backend is not re-imported on every call. get_ocr_info() no longer
constructs an engine — asking a diagnostic question should never trigger the
expensive thing being diagnosed.

Small text is legible again on Linux and macOS (#3). MAX_OCR_WIDTH = 1280
downsampled every wider frame before OCR, which on a 1680px display turned
12px glyphs into 9px ones. Measured on a 1920x1080 frame of monospace text:

backend 1280 (downscaled) 1920 (native)
Windows OCR 5/5 5/5
EasyOCR 0/5 5/5

Windows OCR is indifferent. EasyOCR fails completely — not degraded, zero
candidates. One shared cap was silently correct on the platform this is
developed on and catastrophic on the two it is not. The cap is now per-backend
and overridable with OSWRIGHT_OCR_MAX_WIDTH, where 0 means native
resolution. Windows behaviour is unchanged.

Also fixed: packaging. pyproject.toml resolved the version with
attr = "oswright.__version__", which setuptools reads statically from the
AST, so replacing the literal with an import broke python -m build outright.
Caught by the build gate rather than by any test.

Reasoning and measurements are in docs/ENGINEERING_LOG.md §2.19.

v0.8.1 - listed where clients look

Choose a tag to compare

@Ask-812 Ask-812 released this 26 Aug 16:14

Gets OSWright listed in the official MCP registry, which is how MCP clients
discover servers.

The registry proves that the same person controls both the GitHub repository
and the PyPI package by looking for an mcp-name: marker in the README that
ships inside the package. That marker only reaches PyPI on a release, so this
is one.

  • Badges for PyPI version, CI status, Python versions and licence.
  • POST.md rewritten. It was a draft from v0.3 pitching "every action returns a
    fresh screenshot so the agent always has context" -- precisely the design the
    last eight versions replaced. A launch post that contradicts its own project
    is worse than none.

No functional changes to the library. See v0.8.0 for the perception work and
the measurements.

v0.8.0 - a shippable release, and the evidence for it

Choose a tag to compare

@Ask-812 Ask-812 released this 25 Aug 19:27

The release that makes every improvement since April actually reachable.

pip install oswright has been serving 0.3.1 since April, which cannot
start: it pins mcp[cli]>=1.0, and mcp 2.x removed mcp.server.fastmcp, so a
fresh install resolves to a version the server cannot import. It also pulled
EasyOCR (and PyTorch) on every platform and named the wrong package for Windows
OCR. Those were fixed in v0.4.0 and never shipped.

Verified before publishing, in a clean virtual environment: the wheel installs,
resolves mcp 1.29.1, pulls no PyTorch on Windows, and the console script starts
an MCP server exposing 43 working tools.

What changed since 0.3.1

Perception was rebuilt around one measurement: the median observation
changes 0.012% of the screen's pixels. Re-reading everything does far more work
than the change warrants.

  • Incremental screen model that rescans only what moved
  • Compositor dirty rectangles via hand-written DXGI Desktop Duplication
    bindings: 0.14 ms to establish "nothing changed", against ~33 ms to capture
    a frame and discover it
  • Resolution cascade: memory, then incremental OCR, then the accessibility
    tree, then the application's own text buffer, then a full read
  • Screen atlas that recognises previously-seen screens and verifies by pixels
    rather than by re-reading text
  • Settle detection that waits as long as the interface takes, not a fixed sleep

Measured end to end: latency per step 212 ms to 33 ms, tokens per observation
~2,764 to ~49, post-action wait 300 ms to 61.5 ms.

Evidence, not adjectives

Task success is graded against each application's own state -- UI Automation, or
the window title -- never against OCR, across Calculator, File Explorer, Chrome
and VS Code. Across four configurations accuracy is identical and token cost
falls 23x.

Against Windows-MCP on the same tasks, graded the same way: 19/20 against
their 20/20, at 832 tokens against their 14,053.
Cheaper, and slightly less
reliable. Both numbers are in the README, because I built the harness and
reporting only the flattering half would be worthless.

docs/ENGINEERING_LOG.md records the reasoning, including 28 things that went
wrong.

v0.3.1

Choose a tag to compare

@Ask-812 Ask-812 released this 09 Apr 09:24

v0.3.1: Major OCR accuracy fix. Windows OCR now processes full-resolution images (2x more text detected). Fixed WinRT collection crash, added line-level grouping, filtered single-char noise. Window region shadow border fix. 22 unit + 9 E2E tests passing.

v0.3.0

Choose a tag to compare

@Ask-812 Ask-812 released this 19 Mar 12:33

v0.3.0: Accessibility tree, OCR caching, screenshot diffing, test suite. 35+ MCP tools. New: get_ui_tree, click_ui_element, fill_ui_element (Windows UI Automation for deterministic element finding), wait_for_change (screenshot diff), get_active_window. OCR results cached automatically. 22 automated tests. Security: launch_app shell injection fix.

v0.2.0

Choose a tag to compare

@Ask-812 Ask-812 released this 19 Mar 05:24

v0.2.0 -- Windows OCR, window management, clipboard, app launcher. 30+ MCP tools. Windows OCR is 10x faster than EasyOCR with zero model download. New: list_windows, focus_window, close_window, minimize_window, screenshot_window, get_clipboard, set_clipboard, launch_app, get_ocr_info.

v0.1.0

Choose a tag to compare

@Ask-812 Ask-812 released this 19 Mar 04:48
Add MCP deployment: CLI args, SSE transport, PyPI workflow, Playwrigh…