这是一个 Claude Desktop 扩展，为 Linux/X11 上的 Claude 提供完整的桌面控制能力：截图、鼠标、键盘、窗口管理、剪贴板和应用启动。
它填补了与 Windows-MCP 相同的生态位，但专为 Linux 设计。旨在与 claude-terminal-mcp 配合使用 —— Terminal 处理 shell 命令，而此扩展处理 GUI 操作。
安装此扩展即赋予 Claude 对您桌面的完全控制权。 任何您可以通过键盘和鼠标执行的操作，Claude 都可以通过此工具完成：
将鼠标移动到任何位置并点击任何内容（包括对话框、“是”按钮、打开的聊天窗口中的发送按钮）
在当前获得焦点的任何窗口中输入内容（包括密码字段）
读取和写入您的剪贴板（因此您最近复制的任何内容都是可见的）
启动应用程序
关闭窗口（包括未保存的工作）
请将安装此扩展视为允许某人坐在您的桌前物理操作您的键盘和鼠标。如果机器上有您不希望 Claude 交互的敏感数据、在共享系统上，或者如果您打算让聊天窗口处于无人看管状态，请勿安装此扩展。
claude-terminal-mcp 使用的黑名单式保护在这里并不适用 —— 鼠标点击就是鼠标点击；您无法通过模式匹配来判断意图。v0.1 版本中的安全防护措施包括：(1) 本 README 中的诚实说明，(2) 每个更改系统状态的工具都带有 destructiveHint: true 注解，以便 Claude 自身的推理层能够感知，(3) 安装流程需要显式开启“扩展开发者模式”（显示红色的“未验证”警告）。
Related MCP server: claude-terminal-mcp
包含十四个工具：
工具 | 用途 |
| 截取全屏（如果 |
| 枚举可见窗口及其 id/pid/几何位置/标题。 |
| 将窗口置于前台。 |
| 移动/调整窗口大小。 |
| 请求优雅地关闭窗口。 |
| 将指针移动到绝对屏幕坐标。 |
| 点击左/中/右键；可选坐标。 |
| 从一点拖动到另一点。 |
| 向指定方向滚动 N 次。 |
| 在获得焦点的窗口中输入字符串。 |
| 按下组合键，如 |
| 读取 CLIPBOARD 选择区作为文本。 |
| 将字符串写入 CLIPBOARD。 |
| 分离式启动应用程序（例如 |
所有工具均调用小型、知名的 X11 CLI 工具 —— 无需 npm 依赖。
显示服务器： X11。v0.1 版本不支持 Wayland，因为 Wayland 的安全模型刻意阻止了跨进程输入注入。要检查您当前使用的会话：
echo $XDG_SESSION_TYPE如果显示 wayland，请注销并在登录界面选择“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 文件。
查看红色的“开发者信息未被 Anthropic 验证”警告。如果您信任该来源，请点击 Install。
回到 All extensions，确保 Linux Desktop 已开启。
在聊天中，打开连接器/工具选择器，并为该对话启用 Linux Desktop。
在首次调用工具时，如果服务器检测到缺少 X11 实用程序，会返回清晰的“使用 sudo apt install … 安装”错误提示 —— 您无需阅读完整的 README 即可知道缺少什么。
尝试询问 Claude：
“截个图，告诉我屏幕上有什么。”
“列出我打开的窗口。”
“聚焦 Firefox 窗口。”
“打开 gnome-terminal，然后在里面输入 nvtop。”
“将 'hello world' 复制到我的剪贴板。”
“将 Claude Desktop 窗口拖到屏幕左上角，调整大小为 800×600。”
“在活动窗口中向下滚动三次。”
仅限 X11。 Wayland 需要完全不同的方法（ydotool + 特权守护进程，用于截图的门户 API）。添加 Wayland 支持在路线图中，但并不简单。
无 AT-SPI UI 检查。 v0.1 使用坐标 + 窗口标题工作。语义化目标定位（例如“点击发送按钮”）需要 AT-SPI 检查，这在 Electron/Chromium 应用上很麻烦，值得在 v0.2 中专门处理。
无 OCR。 截图是 PNG；Claude 使用其视觉能力读取它们。这在大多数用例中效果很好，但没有内置的“在屏幕上找到单词 'Cancel' 并点击它”的原语。
黄色“工具结果无法提交”横幅。 这是外观问题；在动态加载工具步骤时触发。同样影响官方的文件系统扩展。这不是本扩展的 Bug。
没有任何数据离开您的机器。 此扩展完全在本地运行：
数据收集： 无。该扩展不会向外发送数据、发出遥测信息或进行任何自身的网络请求。
数据使用与存储： 截图保存在 /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.
