This server enables full Linux/X11 desktop control, allowing interaction with a GUI environment through screenshots, window management, mouse/keyboard input, clipboard operations, and application launching.
Screenshot: Capture full screen or active window as PNG (saved to /tmp/claude-linux-mcp/shots/).
List Windows: Enumerate all visible windows with id, pid, geometry, and title.
Focus Window: Bring a specific window to the foreground by title pattern.
Move/Resize Window: Reposition and/or resize a window by title pattern.
Close Window: Gracefully close a window by title pattern.
Mouse Move: Move the pointer to absolute screen coordinates.
Mouse Click: Click left/middle/right button at current or specified position.
Mouse Drag: Click-and-drag from one coordinate to another.
Mouse Scroll: Scroll up/down/left/right by a configurable number of clicks.
Type Text: Type a string into the focused window with configurable keystroke delay.
Key Press: Send keyboard shortcuts and special key combinations (e.g., ctrl+c, alt+Tab, Return).
Clipboard Get: Read the current X11 clipboard contents.
Clipboard Set: Write text to the X11 clipboard.
Launch App: Spawn any application or shell command (e.g., Firefox, terminal, VS Code).
A Claude Desktop extension that gives Claude full desktop control on Linux/X11: screenshot, mouse, keyboard, window management, clipboard, and app launch.
Fills the same niche as Windows-MCP but for Linux. Built to pair with claude-terminal-mcp — Terminal handles the shell; this handles the GUI.
Installing this extension gives Claude full control over your desktop. Anything you can do with a keyboard and mouse, Claude can do through this tool:
Move your mouse anywhere and click anything (including dialogs, "Yes" buttons, Send buttons in open chat windows)
Type into whatever window currently has focus (including password fields)
Read and write your clipboard (so anything you've copied recently is visible)
Launch applications
Close windows (including unsaved work)
Treat installing this like giving someone physical access to your keyboard and mouse while they sit at your desk. Don't install it on machines with sensitive data you wouldn't want Claude to interact with, on shared systems, or if you're going to leave a chat unattended.
The denylist-style protection used by claude-terminal-mcp doesn't really apply here — a mouse click is a mouse click; you can't pattern-match intent. The safety rails in v0.1 are: (1) honest framing in this README, (2) destructiveHint: true annotations on every tool that changes system state, so Claude's own reasoning layer is aware, (3) the install flow requires explicit Extension Developer mode (red "unverified" warning).
Related MCP server: claude-terminal-mcp
Fourteen tools:
Tool | Purpose |
| Capture full screen (or active window if |
| Enumerate visible windows with id/pid/geometry/title. |
| Bring a window to the foreground. |
| Move/resize a window. |
| Request a window to close gracefully. |
| Move pointer to absolute screen coordinates. |
| Click left/middle/right; optional coords. |
| Drag from → to. |
| Scroll up/down/left/right by N clicks. |
| Type a string into the focused window. |
| Press a combo like |
| Read the CLIPBOARD selection as text. |
| Write a string to the CLIPBOARD. |
| Spawn an application detached (e.g. |
All shell out to small, well-known X11 CLI tools — no npm dependencies.
Display server: X11. Wayland is not supported in v0.1 because Wayland's security model deliberately blocks cross-process input injection. To check which session you're on:
echo $XDG_SESSION_TYPEIf it says wayland, log out and pick "Ubuntu on Xorg" (or your distro's equivalent) at the login screen.
System tools (one-time install):
sudo apt install xdotool wmctrl xclipgnome-screenshot ships with Ubuntu GNOME; if you're on a different DE, install a screenshot tool:
# One of:
sudo apt install gnome-screenshot # GNOME, works everywhere
sudo apt install scrot # Minimal CLI
sudo apt install maim # Modern replacement for scrotOCR (optional, for screenshot_text — added in v0.2):
sudo apt install tesseract-ocr tesseract-ocr-eng
# Add tesseract-ocr-<lang> for other languages (fra, deu, nld, …).If tesseract isn't installed, only screenshot_text is unavailable — the other 14 tools work normally.
Claude Desktop: ≥ 0.10.0 on Linux (bundles a recent Node; no system Node required).
Download LinuxDesktop.mcpb from the latest release.
Claude Desktop → Settings → Extensions → Extension Developer section → Install Extension → select the .mcpb file.
Review the red "developer info not verified by Anthropic" warning. If you trust the source, click Install.
Back on All extensions, make sure Linux Desktop is toggled on.
In a chat, open the connector/tools picker and enable Linux Desktop for that conversation.
On first tool call, the server detects missing X11 utilities and returns a clear "install with: sudo apt install …" error — you don't have to read the full README to discover what's missing.
Try asking Claude:
"Take a screenshot and tell me what's on my screen."
"List my open windows."
"Focus the Firefox window."
"Open gnome-terminal and then type nvtop into it."
"Copy 'hello world' to my clipboard."
"Drag the Claude Desktop window to the top-left corner of the screen, resize it to 800×600."
"Scroll down three times in the active window."
X11 only. Wayland requires a totally different approach (ydotool + privileged daemon, portal APIs for screenshots). Adding Wayland support is on the roadmap but nontrivial.
No AT-SPI UI inspection. v0.1 works with coordinates + window titles. Semantic ("click the Send button") targeting requires AT-SPI inspection, which is messy on Electron/Chromium apps and deserves its own focused v0.2.
No OCR. Screenshots are PNGs; Claude reads them with its vision. That works well for most use cases but has no built-in "find the word 'Cancel' on screen and click it" primitive.
Yellow "Tool result could not be submitted" banner. Cosmetic; fires on dynamic-tool-loading steps. Affects the stock Filesystem extension too. Not this extension's bug.
No data leaves your machine. This extension runs entirely locally:
Data collection: None. The extension does not phone home, emit telemetry, or make any network requests of its own.
Data usage & storage: Screenshots are saved to /tmp/claude-linux-mcp/shots/ so Claude can reference them later in the same conversation. Nothing else is persisted by the extension itself.
Clipboard: clipboard_get() reads whatever is currently on your X11 CLIPBOARD selection and passes it back to Claude Desktop in the tool result. Treat this the same way you'd treat pasting into a chat — don't ask for it if sensitive data is on your clipboard.
Third-party sharing: None. Nothing is transmitted to Anthropic, the extension author, or any third party by this extension. (Claude Desktop itself separately sends tool inputs/outputs to Anthropic as part of the normal chat flow — that's Anthropic's relationship with you, not this extension's.)
Retention: /tmp/claude-linux-mcp/ is cleared at every reboot. To clear manually: rm -rf /tmp/claude-linux-mcp.
Permissions scope: All tools run with your own user's permissions — the same as anything you'd type into a terminal or do with a mouse.
Contact / questions: Open an issue at https://github.com/LukeLamb/claude-linux-mcp/issues.
MIT. Use freely, attribution appreciated, no warranty.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Let ChatGPT, Claude & Cursor use your Mac: email, calendar, iMessage, Teams, files. Local, free.
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Chess MCP for Claude: engine analysis, attack maps, game review. One URL, no install.
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/LukeLamb/claude-linux-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
