mcp-computer-use
Click on "Deploy 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., "@mcp-computer-useIs Claude done with the refactor? Check the Claude window."
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.
mcp-computer-use
English · עברית
A small, read-only MCP server that lets coding agents (Codex, Claude Code, Cline, Antigravity…) ask "what does that window show?" and get back a two-line JSON answer instead of thousands of tokens of raw window text.
Intended to be published publicly on GitHub (MIT). Not published yet.
Why (token savings)
When an agent runs agent-cu itself, the whole accessibility tree / window text lands in its context and is
re-sent on every following step. In our test one "is Claude done?" check cost ~206k tokens (~47k context per
step, ~3% of a ChatGPT Plus 5-hour quota).
This server does the reading locally:
agent-cu text -a <App>reads the window (no model).Code extracts only the status and the last message (Claude Desktop has a dedicated extractor; other apps use a generic "last N chars" fallback). ~1.5 s.
A local Ollama model (default
gpt-oss:20b) summarizes that short text. Measured 4–8 s, correct.The agent receives ~50 tokens of JSON.
qwen3:4b was tested and kept emitting reasoning, so gpt-oss:20b is the default (configurable).
Related MCP server: vision-mcp
Tools
Tool | Description |
| Reads one window and answers. If |
| Heartbeat: server up, local Ollama reachable (auto-started if needed), model replies |
| Unloads the model now and returns |
| Ollama reachable, model pulled, model loaded, memory, free RAM, current keep_alive policy, agent-cu installed. |
No click / type tools: it is read-only by design.
Details extracted by code
For Claude (desktop / Claude Code) the server also reads the accessibility tree (agent-cu snapshot) and returns
details, filled by code (not the model): project, session (chat title), branch, folder, model,
next_step (suggestion sentences, English and Hebrew), failures (e.g. "Finished a background command (1 failed)"),
files (e.g. a new installer), background_tasks, context_used, waiting_for_user (Allow/Deny buttons).
Callers can use these directly. Disable the extra snapshot with MCP_CU_SNAPSHOT_DETAILS=0.
Sessions (optional context between calls)
client (e.g. codex) and session_id (chosen by the client, e.g. fix-ui) are optional; both are
sanitized to [A-Za-z0-9_-], max 64 chars.
Without them every call is independent: the full screen is re-read, "what changed" is not possible and no file is written. Repeated calls without a session get a short
hintsuggesting one.With them the server keeps one small JSON file per pair,
<project>/.sessions/{client}__{session_id}.json(app, project, session, last_message, next_step, status, last 5 questions with short answers, updated_at). Each call reads the file, reads the screen, compares, answers only the question, returnschanged_since_lastand updates the file. The same question on an unchanged screen is answered from the file (cached: true, no model call).A new
session_idreplaces the old one for that client (the old file is deleted), so each client has one active file. Asession_idwithoutclientuses clientdefault.Files not updated for 24 h are deleted on every call (
MCP_CU_SESSION_TTL_HOURS). Folder:MCP_CU_SESSIONS_DIR. No in-memory state is kept.
Ollama auto-start
If OLLAMA_URL points at this machine (127.0.0.1 / localhost) and Ollama does not answer, the server starts
ollama serve itself: detached, hidden window, with OLLAMA_HOST=127.0.0.1:<port from OLLAMA_URL> set only for
the child process (your global OLLAMA_HOST, e.g. a Mac, is never touched), then waits up to 10 s for /api/tags.
Checked on every call without a session and on the first call of a session (new session file); not on every call inside a session. If a call inside a session fails with
OLLAMA_UNREACHABLE, it starts Ollama once and retries once.A port check plus a lock file (
.sessions/ollama-autostart.lock) prevent double starts.ollamais found on PATH or at%LOCALAPPDATA%\Programs\Ollama\ollama.exe.MCP_CU_AUTOSTART_OLLAMA=0disables it;MCP_CU_AUTOSTART_TIMEOUT(default 10).health()reportsollama_autostarted.
Memory release (smart keep_alive)
Single call, no active session: the model stays loaded 3 min (
MCP_CU_KEEP_ALIVE_IDLE).Active session (any
.sessionsfile updated in the last 10 min) orkeep_warm=true: 10 min (MCP_CU_KEEP_ALIVE_SESSION), so the model is released 10 min after the last call.Memory pressure: free RAM is checked before and after each call; below 2048 MB (
MCP_CU_MIN_FREE_MB, 0 = off) the model is unloaded right after answering, even mid-session. A background thread in the server (MCP_CU_MEMORY_WATCH=1, everyMCP_CU_MEMORY_WATCH_INTERVAL=30 s) does the same while the model is loaded.Callers should call
release_model()at the end of a task. Each answer has amemoryfield (keep_alive,reason,was_loaded,free_ram_mb,unloaded_low_memory). CLI:mcp-computer-use --release.
Success:
{"windows_seen": ["Claude"], "status": "finished",
"summary": "Claude finished: 916 tests pass, commit be8b48e pushed, installer built.",
"confidence": 0.95,
"details": {"project": "MyApp-Desktop", "session": "Multimodal work in progress", "branch": "fix/pre-api",
"next_step": "After installing, reopen QUAL.", "failures": ["Finished a background command (1 failed)"]},
"changed_since_last": ["status: working -> finished", "new text in the last message"],
"session": {"client": "codex", "session_id": "bench"},
"model_used": "gpt-oss:20b", "duration_seconds": 6.1,
"memory_mb": 11264.0, "tokens_per_second": 12.1}Failure (the caller can still act on extracted):
{"error": {"code": "MODEL_TIMEOUT", "message": "gpt-oss:20b did not answer within 18s",
"retryable": true, "suggestion": "Retry once (the model may have been cold-loading) or use the raw `extracted` text."},
"windows_seen": ["Claude"],
"extracted": {"status": "finished", "last_message": "…", "extractor": "claude", "truncated": false},
"model_used": "gpt-oss:20b", "timeout_seconds": 18.0, "duration_seconds": 19.6}Error codes: OLLAMA_UNREACHABLE, MODEL_NOT_FOUND, MODEL_TIMEOUT, MODEL_FAILED, AGENT_CU_NOT_INSTALLED,
AGENT_CU_FAILED, APP_NOT_FOUND (includes available_apps), QUESTION_TOO_LONG, EMPTY_QUESTION.
Smart timeout: timeout_base + timeout_per_1k_chars × chars/1000, clamped to [timeout_min, timeout_max],
plus cold_load_extra when /api/ps shows the model is not loaded.
Setup (Windows, PowerShell)
Requirements: Python 3.10+, Node + npm i -g agent-cu, Ollama.
cd C:\Develop\mcp-computer-use
python -m venv .venv
.\.venv\Scripts\Activate.ps1
pip install -e ".[dev]"
pytest -qOllama
The default URL is http://127.0.0.1:11435 (a local instance on a non-default port, because a global
OLLAMA_HOST may point to another machine).
$env:OLLAMA_HOST = "127.0.0.1:11435"; ollama serve # in its own window
$env:OLLAMA_HOST = "127.0.0.1:11435"; ollama pull gpt-oss:20b
mcp-computer-use --health # check everything
mcp-computer-use --ask "Is Claude finished?" --app Claude # one-off testConfiguration
Priority: defaults < TOML file < env vars. File: mcp-computer-use.toml in the working dir,
%USERPROFILE%\.config\mcp-computer-use\config.toml, or MCP_CU_CONFIG=<path> (see mcp-computer-use.example.toml).
Env | Default |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| bundled |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Optional HTTP health: MCP_CU_HEALTH_HTTP=1 (or --health-http) → GET http://127.0.0.1:8765/health
(200 when ok, 503 otherwise).
Register the server
Codex – %USERPROFILE%\.codex\config.toml:
[mcp_servers.computer-use]
command = 'C:\Develop\mcp-computer-use\.venv\Scripts\mcp-computer-use.exe'
args = []
env = { MCP_CU_OLLAMA_URL = "http://127.0.0.1:11435", MCP_CU_MODEL = "gpt-oss:20b" }
startup_timeout_sec = 20
tool_timeout_sec = 120Claude Code:
claude mcp add computer-use --scope user -e MCP_CU_OLLAMA_URL=http://127.0.0.1:11435 -- C:\Develop\mcp-computer-use\.venv\Scripts\mcp-computer-use.exeThen add the AGENTS.md / CLAUDE.md snippet below so agents use it correctly.
How agents should call this server
The server sends these rules to clients on initialize (MCP instructions) and in the tool descriptions:
English only in
question(translate the user's request), one short focused question per call (max 300 chars,MCP_CU_MAX_QUESTION_CHARS), passappwhen known, step by step for bigger checks, never ask it to click/type, and followerror.suggestion.Optionally pass
client+session_idand reuse them for the whole task to get context andchanged_since_last.Call
release_model()when the task is done.Longer questions return
QUESTION_TOO_LONG. Multi-part questions (3+?or a numbered/bulleted list) and mostly non-Latin questions are still answered, with a non-fatalhint.
Good | Bad |
|
|
|
|
|
|
| a 1,000-char paragraph describing everything to check |
Step-by-step example (user asks in Hebrew "תבדוק אם קלוד סיים ומה יצא"):
look_at_screen("Is Claude working or finished?", "Claude", client="codex", session_id="check-claude")→status: finishedlook_at_screen("What is Claude's last message about?", "Claude", client="codex", session_id="check-claude")→ short summaryOnly if needed:
look_at_screen("Did Claude report any failing tests?", ...); later"What changed?"useschanged_since_lastThen answer the user in their language.
Snippet for a global AGENTS.md / CLAUDE.md
Paste into %USERPROFILE%\.codex\AGENTS.md and/or %USERPROFILE%\.claude\CLAUDE.md (also in docs/AGENTS_SNIPPET.md):
## On-screen checks (mcp-computer-use)
To see or check what is on this computer's screen (e.g. "is Claude finished?", "what does Codex show?"),
use the `computer-use` MCP tool `look_at_screen` instead of running agent-cu or screenshots yourself.
- Write `question` in English, even if I write to you in Hebrew or another language.
- One short, focused question per call (under 300 chars). Pass `app` when known ("Claude", "ChatGPT").
- For bigger checks go step by step: first "Is Claude working or finished?", then "What is Claude's last message about?", then any detail.
- Optional: pass `client="codex"` (your name) and a `session_id` you choose for the task (e.g. "check-claude"), and reuse both on every call of that task: answers get shorter and more accurate and `changed_since_last` shows what changed. A new session_id replaces the old one. Without them each call is independent (full re-read, no "what changed").
- Use `details` (project, session, branch, next_step, failures, files) from the result directly.
- To check the bridge before a task, call `ping()` (the first ping can take 30-50 s while the model loads). If the local Ollama is down, the server starts it by itself.
- When the task is done, call `release_model()` to free the local model's memory.
- It is read-only: never ask it to click or type.
- To launch an app, run `powershell -ExecutionPolicy Bypass -File C:\Develop\mcp-computer-use\scripts\cu-open.ps1 <exe|path|uri>` instead of `agent-cu open`, then use the returned `app` with `agent-cu ... -a` and with `look_at_screen(app=...)` (UWP apps such as Calculator are addressed by their localized window title).
- On `error`, follow `error.suggestion` (OLLAMA_UNREACHABLE → call `health()`; MODEL_TIMEOUT → retry once; QUESTION_TOO_LONG → split). If a `hint` is returned, apply it to the next call.Launching apps: scripts/cu-open.ps1
agent-cu open calc.exe --wait starts Calculator but then times out: it waits for an app literally named
calc.exe, while UWP/packaged apps run inside ApplicationFrameHost with a localized title (e.g. מחשבון).
cu-open.ps1 launches anything Start-Process can (exe name, full path, shell: / ms-settings: /
calculator: URIs), polls the open windows every 500 ms until a new window appears (or an existing
single-instance window comes to the front), checks that agent-cu snapshot -a <app> works, and prints one JSON line:
powershell -ExecutionPolicy Bypass -File C:\Develop\mcp-computer-use\scripts\cu-open.ps1 calc.exe
# {"ok":true,"app":"מחשבון","title":"מחשבון","process":"ApplicationFrameHost","pid":16708,"seconds":1.8,"hint":"UWP app hosted by ApplicationFrameHost: use -a 'מחשבון' (the window title).","verified":true}
agent-cu snapshot -a 'מחשבון' -i -c --humanOptions: -Args '<arguments>' (with -File, pass several arguments as one quoted string), -TimeoutSec 15,
-NoVerify (skip the snapshot check). On timeout it prints ok:false with error, new_windows_seen and
frontmost, and exits 1. Use the returned app with every agent-cu ... -a. It never closes or moves other windows.
Output is UTF-8 (Hebrew titles are kept).
Usage examples
look_at_screen("Is Claude finished? What did it report?", "Claude")look_at_screen("What is Claude doing right now?")→ app auto-picked from the questionlook_at_screen("What is the last message in Codex?", "ChatGPT")
Development
src/mcp_computer_use/: server.py (MCP + CLI), core.py (logic), agent_cu.py, extractors.py
(add per-app extractors to EXTRACTORS), ollama_client.py, timeouts.py, config.py, errors.py,
guidance.py (instructions + question validation), prompts/system_prompt.md. Tests mock subprocess and Ollama: pytest -q. Works with mcp 1.x (FastMCP)
and 2.x (MCPServer).
License
MIT
עברית
שרת MCP קטן לקריאה בלבד, שמאפשר לסוכני קוד (Codex, Claude Code, Cline, Antigravity) לשאול "מה מופיע בחלון הזה?" ולקבל תשובת JSON של שתי שורות במקום אלפי טוקנים של טקסט גולמי מהחלון.
הפרויקט מיועד לפרסום פומבי ב-GitHub (רישיון MIT). עדיין לא פורסם.
למה זה חוסך טוקנים
כשהסוכן מריץ agent-cu בעצמו, כל הטקסט של החלון נכנס להקשר שלו ונשלח שוב בכל צעד. בבדיקה שלנו, שאלה אחת
כמו "קלוד סיים?" עלתה כ-206 אלף טוקנים, בערך 3% ממכסת 5 השעות של Plus.
השרת הזה עושה את הקריאה מקומית:
agent-cu text -a <App>קורא את החלון, בלי מודל.קוד שולף רק את המצב ואת ההודעה האחרונה (יש מחלץ ייעודי ל-Claude Desktop, ולשאר התוכנות לוקחים את N התווים האחרונים). כשנייה וחצי.
מודל מקומי ב-Ollama (ברירת מחדל
gpt-oss:20b) מסכם את הטקסט הקצר. נמדד: 4 עד 8 שניות, עם תשובה נכונה.הסוכן מקבל כ-50 טוקנים של JSON.
נבדק גם qwen3:4b, אבל הוא ממשיך "לחשוב בקול", ולכן ברירת המחדל היא gpt-oss:20b. אפשר לשנות אותה.
הכלים
look_at_screen(question, app=None, client=None, session_id=None): קורא חלון אחד ועונה. בליapp, נבחרת התוכנה שמוזכרת בשאלה (כולל כינויים בעברית כמו "קלוד" ו"קודקס"), ואם אין כזו, החלון שבחזית. clientו-session_idהם אופציונליים (ראו "סשנים").
ping(): בדיקת דופק. מוודא שהשרת עונה, ש-Ollama המקומי זמין (ומפעיל אותו אם צריך), ושהמודל עונהpong. לא קורא את המסך. מחזיר{ok, server, ollama, model_reply_ok, model, seconds, cold, error?}. הפינג הראשון יכול לקחת 30–50 שניות כשהמודל עוד לא טעון. משורת הפקודה:--ping.
release_model(): פורק את המודל מהזיכרון מיד ומחזיר כמה זיכרון שוחרר. קוראים לו בסוף משימה.
health(): בודק אם Ollama זמין, אם המודל הורד ונטען, כמה זיכרון הוא תופס, כמה RAM פנוי, מה מדיניות ה-keep_alive הנוכחית ואם agent-cu מותקן.
אין כלים ללחיצה או להקלדה. השרת קורא בלבד.
פרטים שהקוד שולף
ב-Claude (desktop ו-Claude Code) השרת קורא גם את עץ הנגישות (agent-cu snapshot) ומחזיר שדה details שממלא הקוד, לא המודל: הפרויקט (project), שם הסשן (session), הענף (branch), התיקייה (folder), הצעד הבא שהוצע (next_step, באנגלית ובעברית), כשלים כמו פקודת רקע שנכשלה (failures), קבצים כמו התקנה חדשה (files), משימות רקע (background_tasks), וכפתורי אישור שממתינים למשתמש (waiting_for_user). אפשר לכבות עם MCP_CU_SNAPSHOT_DETAILS=0.
הפעלה אוטומטית של Ollama
אם OLLAMA_URL מצביע על המחשב הזה (127.0.0.1 או localhost) ו-Ollama לא עונה, השרת מפעיל בעצמו ollama serve ברקע, בחלון מוסתר, עם OLLAMA_HOST=127.0.0.1:<הפורט מ-OLLAMA_URL> רק לתהליך הזה. ה-OLLAMA_HOST הגלובלי שלך (למשל ה-Mac) לא משתנה. אחר כך הוא מחכה עד 10 שניות ש-/api/tags יענה.
הבדיקה נעשית בכל קריאה בלי סשן, ובקריאה הראשונה של כל סשן, לא בכל קריאה בתוך סשן. אם קריאה באמצע סשן נכשלת עם
OLLAMA_UNREACHABLE, השרת מפעיל את Ollama פעם אחת ומנסה שוב פעם אחת.בדיקת פורט וקובץ נעילה (
.sessions/ollama-autostart.lock) מונעים הפעלה כפולה.את
ollamaהוא מחפש ב-PATH או ב-%LOCALAPPDATA%\Programs\Ollama\ollama.exe.
MCP_CU_AUTOSTART_OLLAMA=0מכבה את ההפעלה האוטומטית. health()מדווחollama_autostarted.
שחרור זיכרון חכם
קריאה בודדת בלי סשן פעיל: המודל נשאר טעון 3 דקות (
MCP_CU_KEEP_ALIVE_IDLE).כשיש סשן פעיל (קובץ ב-
.sessionsשעודכן ב-10 הדקות האחרונות) או כשנשלחkeep_warm=true: 10 דקות (MCP_CU_KEEP_ALIVE_SESSION). המודל משתחרר 10 דקות אחרי הקריאה האחרונה.לחץ זיכרון: לפני כל קריאה ואחריה נבדק כמה RAM פנוי. אם נשארו פחות מ-2048MB (
MCP_CU_MIN_FREE_MB, 0 מכבה), המודל נפרק מיד אחרי התשובה, גם באמצע סשן. בנוסף, חוט רקע בשרת בודק כל 30 שניות כשהמודל טעון ועושה אותו דבר (MCP_CU_MEMORY_WATCH=1).כדאי שהלקוח יקרא ל-
release_model()בסוף המשימה. הכלי פורק את המודל מיד ומחזיר כמה זיכרון שוחרר (freed_mb). בכל תשובה יש שדהmemory.
סשנים (הקשר בין קריאות, אופציונלי)
client (שם הלקוח, למשל codex) ו-session_id (שם שהלקוח בוחר, למשל fix-ui) הם אופציונליים. מותרים רק A-Z a-z 0-9 _ -, עד 64 תווים.
בלעדיהם כל קריאה עומדת בפני עצמה: השרת קורא את כל המסך מחדש, אי אפשר לשאול "מה השתנה", ולא נכתב שום קובץ. אם לקוח שואל כמה פעמים ברצף בלי סשן, מוחזר
hintשמציע להוסיף אותו.איתם השרת שומר קובץ JSON קטן אחד לכל זוג,
<project>/.sessions/{client}__{session_id}.json, עם האפליקציה, הפרויקט, הסשן, ההודעה האחרונה, הצעד הבא, המצב, 5 השאלות האחרונות עם תשובות קצרות וזמן העדכון. בכל קריאה השרת קורא את הקובץ ואת המסך, משווה ביניהם, עונה רק על מה שנשאל, מחזירchanged_since_lastומעדכן את הקובץ. אם נשאלה אותה שאלה והמסך לא השתנה, התשובה נלקחת מהקובץ בלי לפנות למודל (cached: true).
session_idחדש מחליף את הקודם של אותו לקוח, והקובץ הקודם נמחק. לכל לקוח יש תמיד קובץ פעיל אחד.קבצים שלא עודכנו 24 שעות נמחקים בכל קריאה (
MCP_CU_SESSION_TTL_HOURS). את התיקייה אפשר לשנות עםMCP_CU_SESSIONS_DIR. שום דבר לא נשמר בזיכרון.
במקרה של כישלון חוזר error עם code, message, retryable ו-suggestion, ולצדו extracted, הטקסט הקצר שנשלף, כך שהסוכן יכול להמשיך גם בלי המודל.
הקודים: OLLAMA_UNREACHABLE, MODEL_NOT_FOUND, MODEL_TIMEOUT, MODEL_FAILED, AGENT_CU_NOT_INSTALLED, AGENT_CU_FAILED, APP_NOT_FOUND.
זמן קצוב חכם: בסיס, ועוד תוספת לכל 1,000 תווים, בין מינימום למקסימום. אם המודל עוד לא טעון בזיכרון, מתווספת הקצבה לטעינה.
התקנה ב-Windows (PowerShell)
דרישות: Python 3.10 ומעלה, Node עם npm i -g agent-cu, ו-Ollama.
cd C:\Develop\mcp-computer-use
python -m venv .venv
.\.venv\Scripts\Activate.ps1
pip install -e ".[dev]"
pytest -qOllama
כתובת ברירת המחדל היא http://127.0.0.1:11435. זה מופע מקומי על פורט נפרד, כי ה-OLLAMA_HOST הגלובלי שלך מפנה ל-Mac.
$env:OLLAMA_HOST = "127.0.0.1:11435"; ollama serve # בחלון נפרד
$env:OLLAMA_HOST = "127.0.0.1:11435"; ollama pull gpt-oss:20b
mcp-computer-use --health
mcp-computer-use --ask "מה קלוד עושה?" --app Claudeהגדרות
ההגדרות נקבעות לפי סדר עדיפות: ברירות המחדל, מעליהן קובץ TOML, ומעל הכול משתני סביבה. פירוט מלא בטבלה בחלק האנגלי ובקובץ mcp-computer-use.example.toml.
את בדיקת התקינות דרך HTTP מפעילים עם MCP_CU_HEALTH_HTTP=1, ואז היא זמינה בכתובת GET http://127.0.0.1:8765/health.
רישום ב-Codex וב-Claude Code
ב-Codex מוסיפים את הבלוק [mcp_servers.computer-use] לקובץ %USERPROFILE%\.codex\config.toml. ב-Claude Code מריצים claude mcp add computer-use .... הדוגמאות המדויקות מופיעות בחלק האנגלי.
כדאי להוסיף גם ל-AGENTS.md או ל-CLAUDE.md את ההוראה: "כדי לבדוק מה מופיע בחלון במחשב, קרא ל-look_at_screen ואל תריץ agent-cu בעצמך".
איך סוכנים צריכים לפנות לשרת
השרת שולח את הכללים האלה ללקוח כבר בהתחברות (instructions) וגם בתיאורי הכלים:
את
questionכותבים באנגלית בלבד. הסוכן מתרגם בעצמו את מה שהמשתמש ביקש.שאלה אחת קצרה וממוקדת בכל קריאה, עד 300 תווים (אפשר לשנות ב-
MCP_CU_MAX_QUESTION_CHARS).כשהתוכנה ידועה, מעבירים
app.בדיקה גדולה מפצלים לשלבים: קודם המצב, אחר כך הפרטים.
לא מבקשים מהשרת ללחוץ או להקליד.
אפשר (לא חובה) לשלוח
clientו-session_idולהשתמש באותו זוג לאורך כל המשימה, כדי לקבל הקשר ו-changed_since_last.בסוף המשימה קוראים ל-
release_model().כשחוזרת שגיאה, פועלים לפי
suggestion.
שאלה ארוכה מדי מחזירה QUESTION_TOO_LONG. שאלה מרובת חלקים, או שאלה שכתובה ברובה לא באותיות לטיניות (למשל עברית), עדיין מקבלת תשובה, ואיתה hint עם הצעה לשיפור.
טובות: Is Claude working or finished?, What is Claude's last message about?
פחות טובות: מה קלוד עושה? (עובד, אבל מוחזרת המלצה לשאול באנגלית), Is Claude done? Did tests pass? What commit? (כמה שאלות בקריאה אחת), Click Send... (השרת קורא בלבד).
דוגמה לעבודה בשלבים: המשתמש כותב "תבדוק אם קלוד סיים ומה יצא". הסוכן שואל קודם Is Claude working or finished?, אחר כך What is Claude's last message about?, ועונה למשתמש בעברית.
את קטע ההוראות לסוכנים (באנגלית, בחלק האנגלי וגם בקובץ docs/AGENTS_SNIPPET.md) מדביקים בקובץ AGENTS.md הגלובלי של Codex או בקובץ CLAUDE.md של Claude Code.
פתיחת תוכנות: scripts/cu-open.ps1
הפקודה agent-cu open calc.exe --wait פותחת את המחשבון, אבל נכשלת בזמן קצוב: היא מחכה לתוכנה בשם calc.exe, בזמן שתוכנות UWP רצות בתוך ApplicationFrameHost עם כותרת מתורגמת (למשל מחשבון).
הסקריפט cu-open.ps1 פותח כל מה ש-Start-Process יודע לפתוח: שם קובץ, נתיב מלא, או כתובות כמו ms-settings: ו-calculator:. כל חצי שנייה הוא בודק אם נפתח חלון חדש (או אם חלון קיים של תוכנה שרצה במופע יחיד עבר לחזית), מוודא ש-agent-cu snapshot -a <app> עובד, ומדפיס שורת JSON אחת עם ok, app (השם לשימוש ב-agent-cu -a), title, process, pid, seconds ו-hint.
powershell -ExecutionPolicy Bypass -File C:\Develop\mcp-computer-use\scripts\cu-open.ps1 calc.exeאפשרויות: -Args '<ארגומנטים>' (עם -File מעבירים כמה ארגומנטים כמחרוזת אחת במרכאות), -TimeoutSec 15, ו--NoVerify לדילוג על הבדיקה. אם לא נפתח חלון בזמן, מוחזר ok:false עם הסבר, החלונות החדשים שנראו והחלון שבחזית. הסקריפט לא סוגר ולא מזיז חלונות אחרים, והפלט ב-UTF-8 כך שכותרות בעברית נשמרות.
סוכנים צריכים לפתוח תוכנות תמיד דרך cu-open.ps1 ולא דרך agent-cu open.
דוגמאות
look_at_screen("Is Claude working or finished?", "Claude")
look_at_screen("Is Claude finished?", "Claude")
רישיון
MIT
Available Tools
4 toolshealthA
Check the backend before/after errors: Ollama reachable, model pulled and loaded, memory, free RAM, current keep_alive policy, agent-cu installed. Call this first if look_at_screen returns OLLAMA_UNREACHABLE or MODEL_NOT_FOUND.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the specific subsystems inspected, which is useful behavioral detail. Yet it does not state whether the operation is read-only, whether it has side effects (e.g., forcing a model load), or how long it might take. For a diagnostic tool, the checklist is helpful but leaves the safety and side-effect profile implicit.
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?
Two sentences, front-loaded with the concrete checks and followed by the trigger condition. Every clause adds information; no filler. The structure makes it easy to scan for the tool's purpose and call condition.
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?
The tool has no output schema and no annotations, so the description should ideally explain the return shape or at least characterize the response. It lists what is checked but does not say what the agent gets back (e.g., a report with per-check statuses). Given the low complexity, the description is adequate but leaves a notable gap around output interpretation.
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 takes zero parameters, so there is no parameter semantics to explain. Per the rubric, 0 params yields a baseline of 4. The description correctly does not waste words on nonexistent parameters.
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 states a specific verb ('Check') and resource ('backend'), then enumerates exactly what is checked: Ollama reachable, model loaded, memory, free RAM, keep_alive policy, agent-cu installed. This is far more specific than a tautology. It references a sibling tool (look_at_screen) to disambiguate usage, but does not distinguish itself from the sibling 'ping', so it stops short of a 5.
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 gives clear context: use it 'before/after errors' and 'Call this first if look_at_screen returns OLLAMA_UNREACHABLE or MODEL_NOT_FOUND.' This specifies a trigger condition tied to a specific error code. However, it does not articulate when not to use it or how it relates to the sibling 'ping', so it is not fully exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
look_at_screenA
Ask ONE short English question about what a window on this computer shows; get short JSON back
(windows_seen, status, summary, confidence, details, model_used, duration_seconds, memory_mb).
details is filled by code: project, session, branch, next_step, failures, files, background_tasks when found.
Read-only: never clicks or types. Pass app when known. For multi-part checks call step by step
(status first, then details). On error, follow error.suggestion.
client and session_id are OPTIONAL. Without them every call is independent: the full screen is
re-read, no 'what changed' is possible and no file is written. With them the server keeps context
between calls (more accurate, shorter answers, plus changed_since_last). Reuse the same pair for one
task; sending a new session_id replaces the old one for that client.
keep_warm (optional bool) keeps the model loaded 10 min instead of 3 when you will ask again soon.
Call release_model() when your task is done.
| Name | Required | Description | Default |
|---|---|---|---|
| app | No | Optional app/window name, e.g. 'Claude' or 'ChatGPT'. Pass it when known. | |
| client | No | Optional. Your client name, e.g. 'codex' or 'claude' ([A-Za-z0-9_-], max 64). Used with session_id to keep context between calls. | |
| question | Yes | One short, focused question in English (max 300 chars), e.g. 'Is Claude working or finished?'. Split bigger checks into several calls. | |
| keep_warm | No | Optional. true = keep the model loaded 10 min (session value) instead of 3 min, when you will ask again soon without a session_id. | |
| session_id | No | Optional. A session name you choose, e.g. 'fix-ui' ([A-Za-z0-9_-], max 64). Reuse it on every call of the same task to get context and 'changed_since_last'. A new value replaces your previous session. Omit it and each call is independent (full re-read, no file). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses read-only behavior (never clicks or types), the effect of omitting client/session_id (full re-read, no 'what changed', no file written), the effect of providing them (context, changed_since_last, file written), session replacement semantics, and the keep_warm timeouts. That is rich behavioral context beyond the schema.
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?
It is dense and front-loaded with the primary action, then output fields, then behavioral rules. It is slightly long and the session/client paragraph could be tightened, but every sentence earns its place.
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 5-param tool with no output schema and no annotations, the description covers return fields, read-only safety, session behavior, error handling, and cleanup via release_model. An agent has everything needed to call it 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 already 100%, so the baseline is 3. The description still adds value by linking session_id and client to outcomes (context, changed_since_last, full re-read without them) and explaining keep_warm's 10-min vs 3-min load, plus the step-by-step pattern for app filtering. It doesn't add syntax details that the schema lacks, so it falls short of 5.
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 states a specific verb and resource: ask one short question about what a window shows, and returns JSON with named fields. Siblings (ping, health, release_model) are clearly different operations, so differentiation is implicit but obvious.
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?
Explicit guidance: pass `app` when known, for multi-part checks call step by step with status first then details, follow error.suggestion on error, and call release_model() when done. It names when to reuse sessions and when to omit them. Nothing is left to inference about when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pingA
Heartbeat: checks that this bridge works end to end. Confirms the server is up, makes sure the local Ollama is reachable (auto-starts it if needed) and asks the model for 'pong'. No screen reading. Returns {ok, server, ollama, model_reply_ok, model, seconds, cold, error?}. The first ping may take 30-50 s if the model is cold (not loaded); later pings take a few seconds.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the side effect that Ollama is auto-started if needed, the first-call cold-start latency of 30-50s versus a few seconds when warm, and that no screen reading occurs. It could still say more about failure modes, but the 'error?' field and 'cold' flag hint at that.
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?
Front-loaded with the purpose, then the return shape, then the latency caveat — a sensible ordering. It is slightly long with the field-by-field enumeration, but every sentence adds information an agent would want.
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?
There is no output schema, and the description compensates by enumerating the returned fields ({ok, server, ollama, model_reply_ok, model, seconds, cold, error?}). For a zero-parameter diagnostic tool, nothing needed to invoke or interpret it is missing.
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 takes zero parameters, so there is nothing to document and the baseline of 4 applies. The description correctly implies invocation requires no arguments.
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?
States a specific verb+resource ('Heartbeat: checks that this bridge works end to end') and enumerates the exact sub-checks it performs (server up, Ollama reachable, model returns 'pong'). The 'No screen reading' clause implicitly distinguishes it from look_at_screen, but the overlapping sibling 'health' is never addressed, so the differentiation is incomplete.
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?
Usage is only implied by the name and framing — a heartbeat/diagnostic. There is no explicit statement of when to call this versus the sibling 'health' tool, nor any exclusion or prerequisite guidance beyond the latency note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
release_modelA
Unload the local model now and return freed memory_mb. Call it at the end of your task (after your last look_at_screen) so the RAM is free again. Safe to call when nothing is loaded.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the full burden. It discloses the side effect (unloads model, returns freed_mb), the safe-when-empty behavior, and ties the timing to look_at_screen. It does not say whether re-loading is costly or whether concurrent calls conflict, but the essentials are covered.
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?
Two sentences; the purpose and return value come first, then the lifecycle guidance. No waste.
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?
A zero-param, no-output-schema teardown tool needs to explain timing, safety, and return value, and it does all three. Minor gap: it doesn't state the consequence of releasing too early, but that is secondary.
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?
Zero parameters, so baseline is 4. The description does not invent any, correct.
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?
States a specific verb (unload) and resource (the local model), plus the side effect (freed memory_mb). Distinguishes from siblings ping/health/look_at_screen, none of which release resources.
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?
Explicit 'when': at the end of your task, after the last look_at_screen. Also states it is safe when nothing is loaded, removing a common hesitation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
4 tool updates
v0.1.0- First observed
health - First observed
look_at_screen - First observed
ping - First observed
release_model
TDQS
Scored across 4 tools
look_at_screen and release_model are clearly distinct, and ping vs health are separated by intent (lightweight heartbeat vs detailed backend diagnostic). However, both ping and health check Ollama reachability and model status, so an agent could reasonably hesitate between them in a failure scenario.
Naming mixes bare nouns (ping, health) with verb_noun forms (look_at_screen uses verb_preposition_noun, release_model is verb_noun). It stays readable, but there is no single predictable pattern across the four tools.
Four tools is a reasonable, tightly scoped set for a read-only screen-inspection bridge, with three of them being support/lifecycle helpers. It is on the thin side since only one tool performs the core action, but nothing is redundant filler.
For a server literally named 'computer-use', the surface is observation-only: no clicking, typing, window enumeration, or targeted reads beyond a single look_at_screen. The read-only lifecycle (ping, health, release_model) is well covered, but the domain name promises interaction the tool set does not deliver.
Maintenance
Related MCP Connectors
Give agents eyes on any web page: structured context, and changes explained in plain language.
Hosted browser for AI agents: screenshots, post-JS DOM, console, WCAG. No install, no API key.
Serves your design system and coding standards to coding agents, so they stop guessing.
OCR, transcription, file extraction, and image generation for AI agents via MCP.
Related MCP Servers
- AlicenseNot gradedqualityNot gradedmaintenanceEnables LLMs to capture and analyze screenshots of your screen, windows, or regions with smart detection capabilities. Features natural language queries, automatic window targeting, and text enhancement for UI debugging and visual inspection.2MIT
- AlicenseNot gradedqualityDmaintenanceEnables AI-powered vision analysis using local Ollama models. Supports screenshot analysis, OCR, text detection, and health monitoring via MCP protocol.14 npm3MIT
- AlicenseAqualityAmaintenanceEnables AI agents to query Windows process, window, and console information via structured JSON instead of screenshots, reducing token usage by 94-98%.2028 npm1MIT
- AlicenseNot gradedqualityBmaintenanceA lightweight Windows automation MCP server that scopes UI operations to a single target window, offering tools like ReadWindow, PeekWindow, Click, Type, Scroll, Screenshot, and App management with reduced token usage compared to full-desktop alternatives.MIT