This server provides a low-context, state-safe MCP facade to control Windows applications, optimized for inexpensive AI models. Key capabilities include:
Find apps: cu_find_app lists running applications with visible windows, optionally filtered by name.
Observe state: cu_observe returns a compact, query-relevant snapshot of UI controls and a state_id, reducing context up to 99.8%; supports vision settings and optional screenshots.
Act: cu_act executes a single action (click, type, key press, scroll, etc.) against a state; stale states are rejected.
Batch: cu_batch runs a fail-fast sequence of actions with a step limit.
Metrics: cu_metrics retrieves cost and error metrics.
Record & replay: Capture and replay workflows with dynamic target re-location.
Procedural memory: Learn and compose atomic task components.
Vision optimization: Local caching, on-demand cropping, and vision=auto escalation.
Delta updates: Receive compact state changes after actions.
Dynamic UI handling: Re-locate targets in the live UI tree, using coordinates as fallback.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@lean-computer-use-mcp In JianYing, set the subtitle font size to 18"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Low-context, state-safe MCP facade over Open Computer Use for inexpensive agent models such as GPT-5.6 Luna.
pip install "git+https://github.com/Kvxw1105/lean-computer-use-mcp"
# or, without a checkout:
uvx --from "git+https://github.com/Kvxw1105/lean-computer-use-mcp" lean-computer-use serve --fakeWindows prerequisites (runtime only, not needed to install):
open-computer-use 0.3.1 (npm global) on PATH; doctor reports when it
is missing or drifts from the pin.
Optional vision endpoints in ~/.lean-cu/config.json for the OCR -> LLM
visual fallback (lean-computer-use config / config-ui).
cua-driver backend (trycua/cua, MIT) is the default engine when
present (--upstream auto): background-first input that never steals the
mouse or foreground focus, with structured refusals and an explicit
foreground escalation. Install once with
irm https://cua.ai/driver/install.ps1 | iex; auto falls back to
open-computer-use when the binary is missing. Pin with
lean-computer-use serve --upstream cua-driver (or set
LEAN_CU_UPSTREAM_KIND=cua-driver). The same model-visible contract applies;
doctor shows the auto resolution and probes version + daemon state. See
docs/RESEARCH-cua-driver-as-upstream.md
for the comparison and rationale.
See docs/PACKAGING.md for MCP registration, skill packaging, and the release-gate benchmark matrix.
Status: v0.2.0 (pinned upstream
0.3.1). Phase-2 is complete:cu_windowwith occlusion/ambiguity handling, real-input facade fallback with structured errors, extendeddoctor, screenshot-fingerprint stale gate for trivial-tree apps, replay auto-recovery, IME + drag recording, and text-LLM ProviderPool failover. Release gates (success-rate matrix, upstream fixture pin) run in CI; 491 tests pass (1 skipped) and ruff is clean. The real-machine checklist (docs/VERIFICATION.md) ran on a live Windows desktop on 2026-08-11: 7/10 items pass (install/observe, doctor, drag recording, real-input fallback, window ambiguity/occlusion, screenshot-fingerprint stale gate, metrics honesty); 3 need a human at the keyboard (IME pinyin composition, replay stale-injection, cross-app chain). Verification found and fixed two bugs: GBK/UTF-8 upstream output decoding and image-bytes metric semantics. The package builds (uv build) but is not yet published to PyPI, and is not yet recommended for production use.
Related MCP server: WinPilot Computer Use MCP
Open Computer Use works, but every snapshot includes a screenshot and every action returns a full refreshed UI state. On Windows we measured:
Payload | Size |
Default | ~54,000 characters |
Compact | ~2,300 characters |
Screenshot (Base64) | ~405,000 characters, unchanged between presets |
A skill can reduce how often a model observes, but it cannot remove screenshots, action-returned full states, or duplicated tool schemas from the model's context. This project puts a bounded proxy between the model and the upstream server so the model sees only what it needs to complete the task.
Measured on the real desktop (ChatGPT window, 2026-08-05): the default upstream
snapshot costs ~437,779 model-visible characters (55,543 text + 382,236 image
Base64) and 460 nodes; the facade's cu_observe returns an 820-character
payload with 3 controls and no image, a 99.8% reduction in model-visible
context. See docs/BENCHMARKS.md for the full table and
reproduction commands.
Beyond whole-task replay, compile --library and recall learn atomic
components (e.g. jianying::click::button::font-size) and task templates,
then compose new tasks from old building blocks. Replay feeds results back:
successes raise popularity and teach effects, failures raise staleness.
refine lets the model curate the library (aliases, merges, descriptions,
template generalizations) with a human-reviewed apply step. compile --llm
names coordinate-only steps semantically (crucial for UIA-thin apps such as
JianYing), and recall --llm maps Chinese or English intents onto learned
components - measured 72.6% lower model-visible context on the second run of
the same task (see docs/BENCHMARKS.md E12).
See docs/MEMORY.md.
Demonstrate a workflow once, then replay it with far less context:
lean-computer-use record --app JianYing --out recordings/font-size.json
lean-computer-use compile --in recordings/font-size.json --out-dir skills/recorded/subtitle-font-size
lean-computer-use replay --in recordings/font-size.json --runThe recorder captures mouse/keyboard events plus periodic element snapshots
(no screenshots), compiles an editable, intent-based SKILL.md (like the
official macOS-only Codex Record & Replay), and replay re-locates targets in
the live tree - coordinates are only a fallback for custom-rendered UIs.
See docs/RECORDING.md.
flowchart LR
Model[Low-cost model e.g. Luna] --> Skill[lean-computer-use-luna skill]
Skill --> Facade[lean-computer-use-mcp]
Facade --> Cache[Local state + image cache]
Facade --> Upstream[open-computer-use MCP/CLI]
Upstream --> Windows[Windows UIA / screenshot]The facade owns:
compact, query-relevant accessibility output instead of full trees;
state_id-based freshness and stale-state rejection;
local screenshot caching and on-demand cropping;
delta summaries after actions instead of full refreshed states;
per-call metrics for honest before/after cost measurement.
docs/ DESIGN, PROTOCOL, SECURITY, BENCHMARKS
src/ Python MCP server (incl. record/compile/replay CLI)
tests/ unit tests and fixtures
skills/ Codex skill that drives the facade
benchmarks/ benchmark scenario definitions
config/ example agent configurationNon-technical users can manage vision endpoints (base URL / key / model, multi-channel failover) in a browser:
lean-computer-use config-uiIt opens a local Chinese panel at http://127.0.0.1:<port>/?t=<token>: add,
remove, reorder and test endpoints, then save to ~/.lean-cu/config.json
(keys are masked, stored only on your machine). A terminal equivalent exists:
lean-computer-use config list|add|remove|reorder|test. Environment variables
(LEAN_CU_VISION_PROVIDERS etc.) remain a temporary override when set.
git clone https://github.com/Kvxw1105/lean-computer-use-mcp.git
cd lean-computer-use-mcp
uv sync --all-extras
uv run pytestRun a demo server with a fake upstream client (no desktop access):
uv run lean-computer-use serve --fakeMIT
Execute one bounded action against a state_id; stale states are rejected.
| Name | Required | Description | Default |
|---|---|---|---|
| x | No | ||
| y | No | ||
| app | Yes | ||
| key | No | ||
| to_x | No | ||
| to_y | No | ||
| pages | No | ||
| value | No | ||
| action | Yes | ||
| commit | No | ||
| from_x | No | ||
| from_y | No | ||
| state_id | Yes | ||
| direction | No | ||
| click_method | No | ||
| mouse_button | No | ||
| element_index | No | ||
| secondary_action | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral traits. It discloses that stale states are rejected and actions are bounded, which is useful, but it does not mention whether the action mutates state, whether commit=true is required, what side effects occur, or what happens on failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. Every element ('bounded action', 'state_id', 'stale states rejected') adds meaningful value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool's 18 parameters and lack of annotations demand a richer description. The current text does not explain valid action values, the meaning of 'bounded', how stale states are detected, or the role of optional parameters like commit and click_method.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It only mentions state_id and vaguely references 'action' through the term 'bounded action'; the other 16 parameters, including required 'app', are not explained at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Execute'), names the resource ('state_id'), and clarifies the scope ('one bounded action'). It effectively distinguishes cu_act from sibling tools like cu_batch and cu_observe by focusing on a single actionable state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for performing a single action on a state, but it does not explicitly state when to use it over alternatives like cu_batch or cu_observe, nor does it mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a bounded, fail-fast action sequence against one app.
| Name | Required | Description | Default |
|---|---|---|---|
| app | Yes | ||
| steps | Yes | ||
| state_id | Yes | ||
| fail_fast | No | ||
| max_actions | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the sequence is bounded and fail-fast, which are key behavioral traits. However, it does not explain what happens on failure, whether steps are atomic, or the nature of state_id, leaving significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with key modifiers ('bounded', 'fail-fast', 'against one app'). Every word adds value, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool is complex with five parameters and no annotations. The description does not explain how to construct steps, what state_id refers to, or how this tool relates to sibling operations, making it incomplete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. It hints at 'bounded' (max_actions) and 'fail-fast' (fail_fast), but does not explain the structure of steps, the purpose of state_id, or the app parameter, leaving most parameters underdocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a bounded, fail-fast action sequence against one app. This specific verb+resource+scope distinguishes it from siblings like cu_act (single action) and cu_observe (observation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for multi-step actions within one app and highlights bounded/fail-fast behavior, but it does not explicitly state when to use this tool versus alternatives like cu_act or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List running apps with visible windows; optional name filter.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does add a useful filter ('with visible windows'), but it does not state read-only behavior, potential side effects, permission requirements, or how null/empty queries are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. Every part contributes meaning: the action, the resource, and the optional filter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and an output schema, the description covers the core function and filter. Still, it lacks explicit usage guidance and behavioral details, making it adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description compensates by referring to the 'query' parameter as an 'optional name filter', which adds semantic meaning. However, it does not explain matching behavior (substring, exact, case sensitivity) or the effect of null, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and identifies the resource as 'running apps with visible windows', including an optional 'name filter'. This clearly distinguishes it from sibling tools like cu_act or cu_observe, which suggest different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to see running apps with visible windows, but it does not explicitly state when not to use this tool or mention alternative tools. Usage context is implied but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return aggregate cost and error metrics for this process.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states 'Return...' implying a read-only operation, but it does not specify data freshness, whether it aggregates historical data, or any potential side effects. The description is too sparse to provide meaningful transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler or redundancy. It is front-loaded with the verb and resource, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description is minimally sufficient but lacks context on when to invoke it versus siblings and any behavioral details. The output schema likely documents return values, but the description could mention typical use cases or limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema trivially covers everything. The description adds meaning by explaining what the tool returns, which is sufficient given there are no inputs to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and resource ('aggregate cost and error metrics'), clearly scoped to 'this process.' It distinguishes itself from siblings like cu_observe (raw observation) and cu_act (actions) by focusing on metrics aggregation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its usage—call to retrieve cost/error metrics—but provides no explicit guidance on when to use it over siblings like cu_observe or cu_metrics. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compact state read for one app; returns top-K controls and a state_id.
| Name | Required | Description | Default |
|---|---|---|---|
| app | Yes | ||
| intent | No | ||
| preset | No | ||
| vision | No | auto | |
| max_results | No | ||
| output_mode | No | controls | |
| include_screenshot | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It explicitly says 'state read' (safe, read-only) and 'compact' with 'top-K controls' (not exhaustive), which is meaningful. It doesn't cover permissions or side effects, but for a read tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, tightly worded sentence that immediately states the tool's purpose and return values. Every word earns its place; no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema, the description is too sparse for a tool with 7 parameters and no annotations. It omits key parameters like output_mode, vision, and preset, and offers no usage alternatives. The core idea is present but not enough for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only adds meaning for 'app' (one app) and 'top-K' (max_results indirectly). Seven parameters exist, but intent, preset, vision, output_mode, and include_screenshot are unexplained in both schema and description, leaving a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this is a 'Compact state read for one app' with a specific verb ('read') and resource ('one app'), and it names the return values ('top-K controls and a state_id'). This clearly distinguishes it from siblings like cu_act (actions) and cu_metrics (metrics).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is implied: use this when you need a compact state read for a single app. However, there is no explicit guidance on when not to use it or alternatives like cu_metrics or cu_find_app.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0cu_actcu_batchcu_find_appcu_metricscu_observeEach tool has a distinct role: finding apps, observing state, executing single actions, batch actions, and metrics. No functional overlap between tools, and the descriptions clearly differentiate them.
All tools share the 'cu_' prefix and are short, but the second part mixes verbs (find, observe, act, batch) with a noun (metrics). This is a minor deviation from a consistent verb-focused pattern.
With only 5 tools, the server is lean and well-scoped. Each tool handles a core capability (discover, observe, act, batch, monitor), and the count feels right for the stated purpose.
The tools cover the essential lifecycle for computer use: finding an app, observing its state, performing actions (single or batched), and tracking metrics. There are no obvious dead ends or missing core operations.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Memory that reasons: continual learning for stateful agents. Better context, fewer tokens.
SaaS intelligence for AI agents. 5 unified tools cover 1,000+ services with 91-96% token savings.
Long-term memory for AI agents: durable records, observable retrieval, governed context assembly.
Codebase intelligence for agents: 152 structured artifacts across 21 programs, one call.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Kvxw1105/lean-computer-use-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
