Claude DesktopにLinux/X11の完全なデスクトップ制御機能（スクリーンショット、マウス、キーボード、ウィンドウ管理、クリップボード、アプリ起動）を提供する拡張機能です。
Windows-MCPのLinux版としての役割を果たします。claude-terminal-mcpと組み合わせて使用するように構築されており、ターミナルがシェルを、本拡張機能がGUIを操作します。
この拡張機能をインストールすると、Claudeにデスクトップの完全な制御権が与えられます。 キーボードとマウスでできることはすべて、Claudeがこのツールを通じて実行可能です：
マウスをどこへでも移動させ、あらゆる場所をクリックする（ダイアログ、「はい」ボタン、開いているチャットウィンドウの送信ボタンなど）
現在フォーカスされているウィンドウに文字を入力する（パスワードフィールドを含む）
クリップボードの読み書きを行う（最近コピーしたものはすべて閲覧可能）
アプリケーションを起動する
ウィンドウを閉じる（未保存の作業を含む）
このインストールは、誰かがあなたのデスクに座り、キーボードとマウスを物理的に操作できるようにすることと同等です。Claudeに触れられたくない機密データがあるマシン、共有システム、またはチャットを放置する可能性がある場合にはインストールしないでください。
claude-terminal-mcpで使用されているような拒否リスト形式の保護は、ここではあまり適用されません。マウスのクリックは単なるクリックであり、意図をパターンマッチングすることはできないためです。v0.1における安全策は以下の通りです：(1) このREADMEでの正直な説明、(2) システム状態を変更するすべてのツールに対する destructiveHint: true アノテーション（Claude自身の推論レイヤーが認識できるようにするため）、(3) インストールフローで明示的な「拡張機能開発者モード」（赤い「未検証」の警告）が必要であること。
Related MCP server: claude-terminal-mcp
14種類のツール：
ツール | 目的 |
| フルスクリーン（ |
| 表示されているウィンドウをID/PID/ジオメトリ/タイトルで列挙します。 |
| ウィンドウを最前面に表示します。 |
| ウィンドウの移動/リサイズを行います。 |
| ウィンドウを正常に閉じるよう要求します。 |
| ポインタを絶対画面座標に移動します。 |
| 左/中央/右クリック。座標はオプション。 |
| ドラッグ操作。 |
| Nクリック分、上下左右にスクロールします。 |
| フォーカスされたウィンドウに文字列を入力します。 |
|
|
| CLIPBOARD選択範囲をテキストとして読み取ります。 |
| 文字列をCLIPBOARDに書き込みます。 |
| アプリケーションをデタッチ状態で起動します（例: |
すべて、よく知られた小さなX11 CLIツールを呼び出す仕組みであり、npmの依存関係はありません。
ディスプレイサーバー: X11。Waylandはv0.1ではサポートされていません。Waylandのセキュリティモデルはプロセス間入力インジェクションを意図的にブロックするためです。現在のセッションを確認するには：
echo $XDG_SESSION_TYPEwaylandと表示された場合は、ログアウトしてログイン画面で「Ubuntu on Xorg」（またはお使いのディストリビューションの同等のもの）を選択してください。
システムツール（初回のみインストール）:
sudo apt install xdotool wmctrl xclipgnome-screenshotはUbuntu GNOMEに同梱されています。別のデスクトップ環境を使用している場合は、スクリーンショットツールをインストールしてください：
# One of:
sudo apt install gnome-screenshot # GNOME, works everywhere
sudo apt install scrot # Minimal CLI
sudo apt install maim # Modern replacement for scrotOCR（オプション、screenshot_text用 — v0.2で追加）:
sudo apt install tesseract-ocr tesseract-ocr-eng
# Add tesseract-ocr-<lang> for other languages (fra, deu, nld, …).tesseractがインストールされていない場合、screenshot_textのみが使用不可となり、他の14個のツールは通常通り動作します。
Claude Desktop: Linux版 ≥ 0.10.0（最新のNodeがバンドルされているため、システム側のNodeは不要です）。
最新リリースから LinuxDesktop.mcpb をダウンロードします。
Claude Desktop → Settings → Extensions → Extension Developer セクション → Install Extension → .mcpb ファイルを選択します。
赤い「developer info not verified by Anthropic」という警告を確認します。ソースを信頼できる場合は Install をクリックします。
All extensions に戻り、Linux Desktop がオンになっていることを確認します。
チャット内でコネクタ/ツールピッカーを開き、その会話に対して Linux Desktop を有効にします。
最初のツール呼び出し時に、サーバーが不足しているX11ユーティリティを検出し、「sudo apt install … でインストールしてください」という明確なエラーを返します。何が不足しているかを知るためにREADMEをすべて読む必要はありません。
Claudeに以下のように尋ねてみてください：
「スクリーンショットを撮って、画面に何が映っているか教えて。」
「開いているウィンドウをリストアップして。」
「Firefoxウィンドウにフォーカスして。」
「gnome-terminalを開いて、その中で nvtop と入力して。」
「'hello world' をクリップボードにコピーして。」
「Claude Desktopウィンドウを画面の左上隅にドラッグして、800×600にリサイズして。」
「アクティブなウィンドウで3回下にスクロールして。」
X11のみ。 Waylandは全く異なるアプローチ（ydotool + 特権デーモン、スクリーンショット用のポータルAPI）が必要です。Waylandサポートの追加はロードマップにありますが、簡単ではありません。
AT-SPI UIインスペクションなし。 v0.1は座標とウィンドウタイトルで動作します。セマンティックな（「送信ボタンをクリック」のような）ターゲット指定にはAT-SPIインスペクションが必要ですが、これはElectron/Chromiumアプリでは複雑であり、v0.2で重点的に取り組む予定です。
OCRなし。 スクリーンショットはPNGであり、Claudeは視覚機能で読み取ります。ほとんどのユースケースではうまく機能しますが、「画面上の『キャンセル』という単語を見つけてクリックする」といった組み込みのプリミティブはありません。
「Tool result could not be submitted」という黄色いバナー。 装飾的なもので、動的ツール読み込みステップで発生します。標準のFilesystem拡張機能にも影響します。この拡張機能のバグではありません。
データはマシンから外部へ送信されません。 この拡張機能は完全にローカルで実行されます：
データ収集: なし。拡張機能は外部への通信、テレメトリの送信、独自のネットワークリクエストの実行を行いません。
データの使用と保存: スクリーンショットは /tmp/claude-linux-mcp/shots/ に保存され、Claudeが同じ会話内で後から参照できるようにします。それ以外は拡張機能自体によって永続化されることはありません。
クリップボード: clipboard_get() は現在X11のCLIPBOARD選択範囲にあるものを読み取り、ツール結果としてClaude Desktopに渡します。これはチャットへの貼り付けと同じように扱ってください。機密データがクリップボードにある場合は、実行しないでください。
第三者への共有: なし。この拡張機能によってAnthropic、拡張機能の作成者、または第三者にデータが送信されることはありません。（Claude Desktop自体は、通常のチャットフローの一部としてツール入力/出力をAnthropicに送信しますが、これはAnthropicとユーザー間の関係であり、本拡張機能とは無関係です。）
保持: /tmp/claude-linux-mcp/ は再起動のたびにクリアされます。手動でクリアするには rm -rf /tmp/claude-linux-mcp を実行してください。
権限スコープ: すべてのツールはユーザー自身の権限で実行されます。ターミナルで入力したりマウスで行ったりする操作と同じです。
連絡先 / 質問: https://github.com/LukeLamb/claude-linux-mcp/issues でIssueを作成してください。
MIT。自由に使用してください。帰属表示を歓迎しますが、保証はありません。
Read the current X11 CLIPBOARD selection as text.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so description adds the X11 and text-layer context. However, it does not disclose behavior for empty or non-text clipboard contents, nor platform dependence beyond X11.
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?
Single sentence with direct verb+object. No wasted words, front-loaded with purpose.
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 0-parameter read tool with readOnlyHint, the description fully covers what the tool does and its data source. No output schema needed for a text return.
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?
No parameters in schema, so description does not need to explain them. The baseline for 0 parameters is 4; description is concise and clear.
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?
Description clearly states it reads the X11 CLIPBOARD selection as text, which is a specific verb+resource. It distinguishes from clipboard_set, which writes.
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?
No explicit guidance on when to use this tool versus alternatives like screenshot_text or type_text. Simple read operation but lacks context on prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write a string to the X11 CLIPBOARD selection.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint: true, so the tool is marked as destructive. The description adds minimal behavioral information beyond stating it writes to the clipboard. It could mention that it overwrites existing clipboard content or is X11-specific, but it does not. With annotations covering the destructive nature, a score of 3 is appropriate.
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 that conveys everything necessary. No wasted words; every word 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?
Given the low complexity (1 param, no output schema, annotations present), the description is mostly complete. It mentions the specific X11 selection, which is useful context. However, it could clarify that it overrides clipboard content and is limited to X11 environments. Still, it is sufficient for an agent to use 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?
The input schema has one parameter 'text' with no description (0% coverage). The description implicitly identifies it by saying 'Write a string', which matches the schema type. However, it does not add additional meaning such as format constraints, max length, or encoding. It adds marginal value over the schema alone.
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 action ('Write a string') and the resource ('to the X11 CLIPBOARD selection'), distinguishing it from sibling tools like clipboard_get. It is specific and unambiguous.
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 does not explicitly state when to use or not use this tool versus alternatives. However, given the sibling tool clipboard_get, the purpose is implicitly clear. No exclusions or alternative suggestions are provided, making it adequate but not thorough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Request a window matching the given title pattern to close (gracefully, via the WM close hint).
| Name | Required | Description | Default |
|---|---|---|---|
| title_pattern | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations by mentioning 'gracefully' and 'via the WM close hint'. However, it does not fully disclose potential consequences (e.g., unsaved changes) or clarify that it is a destructive action beyond the annotation.
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, concise sentence with no extraneous words. It is front-loaded with the action and efficiently conveys the necessary information.
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 tool with one parameter and no output schema, the description covers the core functionality and parameter meaning. It is complete enough for an agent to use the tool correctly, though additional context about failure modes or preconditions would be helpful.
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?
With schema coverage at 0%, the description adds essential meaning: it specifies that the parameter is a 'title pattern' used for matching, not an exact title. This clarifies usage but could provide examples or pattern syntax.
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's purpose: to request closing a window matching a given title pattern. It uses a specific verb ('close') and resource ('window'), and differentiates from siblings like 'focus_window' and 'list_windows'.
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?
No guidance on when to use this tool versus alternatives. The description implies graceful closing but does not provide explicit conditions or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bring a window matching the given title pattern (substring, case-insensitive per wmctrl) to the foreground.
| Name | Required | Description | Default |
|---|---|---|---|
| title_pattern | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the matching behavior (substring, case-insensitive) beyond the annotation's destructiveHint. It adds value by detailing how the pattern is matched. No contradiction with annotations, though destructiveHint seems misaligned.
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 that is front-loaded with the key action and resource. No wasted words; every part is necessary.
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 tool with one parameter and no output schema, the description is fully complete. It covers the purpose, matching behavior, and implicitly the effect. No gaps remain.
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 input schema provides no description for 'title_pattern' (0% coverage). The description compensates by clarifying that it is a substring, case-insensitive pattern. This is essential information for correct invocation.
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 action (bring to foreground) and the resource (window matching title pattern), and specifies matching semantics (substring, case-insensitive). This distinguishes it from sibling tools like close_window or move_window.
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 focusing an existing window but does not explicitly state when to use this tool versus alternatives like list_windows or move_window. No exclusion criteria or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Press a keyboard combination using xdotool's keysym notation. Examples: 'ctrl+c', 'alt+Tab', 'super', 'Return', 'Escape', 'Page_Down'.
| Name | Required | Description | Default |
|---|---|---|---|
| combo | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set destructiveHint=true, so the description does not need to emphasize destructiveness. It adds value by specifying the notation (xdotool's keysym) but could disclose side effects like focus changes or system-level impact. With annotations covering the safety profile, a 3 is appropriate.
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 very concise: two sentences with no wasted words. It front-loads the action and notation, then immediately provides examples. 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 simple tool with one parameter and no output schema, the description is fairly complete. It covers the action, notation, and examples. Minor omission: it doesn't state that the press is instantaneous or that it simulates press and release. Still, it's sufficient given the tool's simplicity.
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 for the 'combo' parameter is 0%, so the description must compensate. It does so by providing examples and explicitly mentioning 'xdotool's keysym notation', which clarifies the format expected. This adds significant semantic value beyond the bare schema.
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 it presses a keyboard combination using xdotool's keysym notation, with concrete examples. It specifies the verb 'Press' and the resource 'keyboard combination', making it unambiguous and distinct from siblings like type_text or mouse_click.
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 provides examples but offers no guidance on when to use this tool versus alternatives like type_text (for typing strings) or mouse_actions. There is no mention of when not to use it, prerequisites, or exclusions, which limits its helpfulness for selection decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Launch an application via a shell command (e.g. "firefox", "gnome-terminal", "code /path/to/project"). The process is detached from this server.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint, openWorldHint), the description adds that 'The process is detached from this server', informing users that the tool does not wait for the process and is non-blocking. This is valuable behavioral context not captured by annotations.
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 two sentences, front-loaded with the action and examples. Every sentence adds value: the first defines the tool, the second adds a key behavioral detail. No redundant or unnecessary content.
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?
Given the tool's simplicity (one parameter, no output schema), the description covers all essential aspects: what it does, how to use it (with examples), and a critical behavioral detail (detached process). No further information is needed for correct 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?
With 0% schema description coverage, the description compensates by explaining that the 'command' parameter is a shell command like 'firefox' or 'code /path/to/project', adding meaning and usage examples beyond the basic string type in the schema.
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 'Launch an application via a shell command', providing a specific verb and resource. Examples like 'firefox', 'gnome-terminal', and 'code /path/to/project' further clarify the tool's purpose, and it is well-differentiated from sibling tools that handle clipboard, windows, or mouse 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 provides clear context on when to use the tool by specifying it launches applications via shell commands and noting the process is detached. It does not explicitly exclude use cases or mention alternatives, but the examples and context make the usage straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all visible windows with id, pid, desktop, geometry (x/y/width/height), hostname, and title.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description specifies the output fields beyond the readOnlyHint annotation, which already marks it as safe. However, it does not disclose additional behavioral traits like whether visible windows are limited to the current host, ordering, or performance implications. The annotation covers the safety aspect, so the description adds moderate value.
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, information-dense sentence that directly states the tool's purpose and deliverables. It is front-loaded with the verb 'List' and avoids any extraneous words.
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 parameterless list operation, the description adequately covers the action and the output details. It could be slightly stronger if it clarified the scope (e.g., current display, local machine). However, given no output schema, the description is complete enough for an AI agent to understand the tool's value.
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 input schema has zero parameters, so the description does not need to explain param meaning. By default, a tool with no parameters gets a baseline score of 4.
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 explicitly states the verb 'List' and the resource 'visible windows', and enumerates the fields returned (id, pid, desktop, geometry, title, etc.). This clearly differentiates from sibling tools like close_window, focus_window, or move_window, which perform distinct 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?
No guidance is provided on when to use this tool versus alternatives such as focus_window or close_window. There is no advice on prerequisites, nor on when not to use it, leaving the agent to infer context from the tool's name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Click a mouse button. If x and y are provided, the pointer moves there first; otherwise clicks at the current pointer location.
| Name | Required | Description | Default |
|---|---|---|---|
| button | No | Default: left. | |
| x | No | ||
| y | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by explaining the conditional pointer movement. Annotations provide destructiveHint for safety awareness, and the description complements this with operational detail.
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, well-structured sentence that front-loads the key purpose and critical behavior. No unnecessary words.
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 action tool with no output schema, the description covers the main behavior and parameter interaction. It assumes agent awareness of standard UI concepts, which is reasonable.
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 description explains the role of x and y together (pointer movement before click), adding context beyond the schema's minimal descriptions. For button, the schema already provides default, so the description doesn't need repetition.
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 clicks a mouse button, with optional movement to specified coordinates. It effectively distinguishes from sibling tools like 'mouse_move' and 'mouse_drag' by specifying its unique action.
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 when to use this tool (for clicking) versus alternatives like mouse_move or mouse_drag. However, it does not explicitly state when not to use it or mention any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Drag from (x1, y1) to (x2, y2) while holding the given button (default left).
| Name | Required | Description | Default |
|---|---|---|---|
| x1 | Yes | ||
| y1 | Yes | ||
| x2 | Yes | ||
| y2 | Yes | ||
| button | No | Default: left. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the basic behavior of dragging with coordinates and a button. The annotations include destructiveHint: true, which warns of potential side effects. However, the description does not elaborate further on behavioral traits (e.g., coordinate system reference, effects on UI) beyond what the annotation already provides.
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 of 15 words, efficiently conveying the core action and default button. No redundant information. Very concise.
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?
Given the tool has 5 parameters including coordinate pairs, the description lacks critical details such as coordinate reference frame (screen vs window), units (pixels?), what happens if coordinates are out of bounds, and return behavior. The destructive hint suggests potential side effects but these are not explained. The description is too minimal for full agent decision-making.
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 20% (only 'button' has a description). The description mentions the parameters but does not explain the coordinate system, units, or value ranges (e.g., are coordinates screen-relative?). The button options are listed but defaults are stated. The description fails to compensate for the low schema coverage.
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?
Description clearly states the action: drag from (x1,y1) to (x2,y2) holding a button (default left). It uses a specific verb ('drag') and resource (coordinates), and is distinguishable from sibling tools like mouse_click and mouse_move.
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?
No explicit guidance on when to use this tool vs alternatives like mouse_click or mouse_move. No prerequisites or when-not-to-use instructions are provided. The destructive hint annotation offers some caution but not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move the mouse pointer to absolute screen coordinates (x, y).
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | ||
| y | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include destructiveHint: true, which the description does not contradict. However, the description does not add further behavioral details (e.g., instant movement, no animation). Baseline score with annotations present.
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?
Single sentence with no wasted words; front-loaded with key information.
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 tool with two numeric parameters and no output schema, the description is nearly complete. Could be improved by clarifying coordinate origin or units.
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%, so the description compensates by explaining that x and y are 'absolute screen coordinates', adding meaning beyond the raw numeric types.
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 specifies the action (move), resource (mouse pointer), and that coordinates are absolute screen coordinates. It distinguishes from sibling tools like mouse_click or mouse_drag.
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?
No guidance on when to use this tool versus alternatives like mouse_drag or mouse_scroll. No mention of prerequisites or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scroll in a direction (up/down/left/right) by N clicks (default 3).
| Name | Required | Description | Default |
|---|---|---|---|
| direction | Yes | ||
| amount | No | Number of scroll clicks. Default 3. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint: true indicates the action modifies state, but the description only adds the default amount. It does not elaborate on the scope (e.g., active window) or any side effects beyond the basic scroll.
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?
Single sentence, no fluff, directly communicates the action and key defaults.
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 tool with two parameters and no output schema, the description covers the essential info. Could be improved by specifying the target window or that scroll is relative, but overall adequate.
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 50% and the description only restates the enum values and default amount already present in the schema. It does not add meaning beyond the schema for either parameter.
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 action (scroll) and the resource (direction and amount). It distinguishes from sibling tools like mouse_click and mouse_drag by specifying scrolling in four directions.
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?
No guidance is provided on when to use this tool versus alternatives, such as scrolling vs clicking or dragging. No mention of prerequisites or contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move and/or resize a window matching the given title pattern. Any of x, y, width, height omitted leaves that dimension unchanged.
| Name | Required | Description | Default |
|---|---|---|---|
| title_pattern | Yes | ||
| x | No | ||
| y | No | ||
| width | No | ||
| height | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by explaining that omitted dimensions remain unchanged. However, it lacks details on pattern matching behavior and potential side effects.
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, no redundancy. Purpose and key behavioral rule are front-loaded and efficiently communicated.
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?
While the description covers core purpose and parameter behavior, it omits information about return values, error cases, and handling of multiple matching windows, making it somewhat incomplete for a 5-parameter tool.
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?
With 0% schema description coverage, the description adds meaning for the optional parameters (omitted leaves unchanged) but does not clarify the title_pattern format or coordinate semantics.
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 action 'Move and/or resize a window' and specifies the resource by 'title pattern', distinguishing it from sibling tools like close_window or focus_window.
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 moving/resizing windows but does not provide explicit guidance on when to use this tool over alternatives, nor does it mention prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture a screenshot of the full screen (or the active window if active_window=true). Saves a PNG under /tmp/claude-linux-mcp/shots/ and returns the path.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Optional target path. Defaults to /tmp/claude-linux-mcp/shots/shot-<ts>.png. | |
| active_window | No | If true, capture only the currently-focused window instead of the full screen. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses file format (PNG), save location (/tmp/claude-linux-mcp/shots/), and return value (path). Annotations include readOnlyHint=true, which is not contradicted; the tool is a read operation with minimal side effects.
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 concise sentences front-load the main action and optional behavior. No unnecessary words 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?
For a simple tool with full parameter coverage and annotations, the description covers purpose, parameters, output, and side effects. No gaps exist given the lack of an output schema.
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 100%, so baseline is 3. The description adds the default path and clarifies the behavior of 'active_window', providing value beyond the schema.
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 verb 'capture' and the resource 'screenshot', and distinguishes between full screen and active window. It contrasts with the sibling tool 'screenshot_text' which extracts text.
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 visual capture but does not explicitly state when to use versus alternatives like 'screenshot_text' or specify when not to use. No exclusions or context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take a screenshot and OCR it with tesseract. Returns the recognized text plus the path to the underlying PNG. Use when Claude needs to READ what is on screen (log windows, error dialogs, terminal output in non-focused windows) rather than just see the image. Requires tesseract-ocr installed.
| Name | Required | Description | Default |
|---|---|---|---|
| active_window | No | If true, capture only the currently-focused window. Default false (full screen). | |
| path | No | Optional target path for the PNG. Defaults to /tmp/claude-linux-mcp/shots/shot-<ts>.png. | |
| lang | No | Tesseract language code (e.g. "eng", "fra", "deu", "nld", or "eng+fra" for multi). Default "eng". Requires the matching tesseract-ocr-<lang> package. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, and the description confirms it reads the screen. It discloses that it requires external software (tesseract-ocr) and describes the output (text + path). No contradictions.
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?
Three sentences with no wasted words. Front-loaded: action first, then output and usage guidance.
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?
Covers purpose, output, usage context, and prerequisites. Lacks details on error handling (e.g., tesseract not installed) but is sufficient given no output schema.
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 already provides 100% coverage of parameter descriptions. The description adds no additional meaning for parameters beyond what is in the schema. Baseline 3 is appropriate.
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 action (take screenshot and OCR), the resource (screen), and the output (recognized text plus PNG path). It distinguishes from sibling tools like screenshot, which likely only captures the image.
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?
Provides explicit context for when to use this tool: 'when Claude needs to READ what is on screen' and gives concrete examples (log windows, error dialogs). It does not mention when not to use or alternative tools, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Type a string into the currently-focused window (emits keystrokes). Use key_press for special/modifier combos.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| delay | No | Milliseconds between keystrokes. Default 12. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds that it emits keystrokes and targets the focused window, which complements the destructiveHint annotation without contradiction.
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 clear, well-structured sentences that efficiently convey purpose and usage guidance.
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?
Covers tool purpose and alternative usage, but lacks details like error handling, cancellation, or behavior without a focused window.
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 schema has 50% description coverage; the description only paraphrases the text parameter and does not explain the delay parameter beyond what the schema provides.
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 types a string into the currently-focused window and distinguishes it from key_press for special/modifier combos.
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?
Explicitly tells when to use key_press instead, but doesn't provide other usage context like prerequisites or when not to use.
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.
v0.2.0screenshot_textv0.1.0clipboard_getclipboard_setclose_windowfocus_windowkey_presslaunch_applist_windowsmouse_clickmouse_dragmouse_movemouse_scrollmove_windowscreenshottype_textScored across 15 tools
Each tool has a clearly distinct purpose covering clipboard operations, window management, keyboard input, mouse actions, app launching, and screenshot capture. No two tools overlap in functionality.
All tool names follow a consistent verb_noun pattern with snake_case (e.g., clipboard_get, close_window, mouse_click). The naming scheme is predictable and easy to parse.
15 tools is perfectly scoped for a desktop automation MCP server. Each tool addresses a distinct action without unnecessary redundancy, covering the essential operations for window management, input, and clipboard.
The tool surface covers the full lifecycle of desktop automation: window discovery and manipulation, input simulation (keyboard, mouse, clipboard), app launching, and screenshot capture with optional OCR. No obvious gaps are present for typical use cases.
Use your Mac, Windows or Linux computer from ChatGPT, Claude or Codex: files, commands, documents.
Work on your own computers from Claude or ChatGPT: run commands, edit and search files.
Shared memory and actions for Claude, Kiro, OpenAI, Cursor, and other MCP-compatible AI clients.
Chess MCP for Claude: engine analysis, attack maps, game review. One URL, no install.
