Wayland MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| VLM_MODEL | No | Model identifier. Defaults: 'qwen/qwen2.5-vl-72b-instruct:free' for OpenRouter or 'gemini-2.5-flash' for Gemini. | |
| VLM_PROVIDER | No | Vision provider: 'openrouter' or 'gemini' | openrouter |
| GEMINI_API_KEY | No | Google Gemini API key | |
| WAYLAND_DISPLAY | Yes | Display identifier (e.g., wayland-0) | |
| XDG_RUNTIME_DIR | Yes | Wayland runtime directory (e.g., /run/user/1000) | |
| WAYLAND_MCP_PORT | No | Server listen port | 4999 |
| OPENROUTER_API_KEY | No | OpenRouter API key |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": true
} |
| resources | {
"subscribe": false,
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| move_mouseB | Move mouse to specified screen coordinates. Args: x: Horizontal position (0 = left) y: Vertical position (0 = top) relative: If True, moves relative to current position (default: False) Returns: dict: { 'success': bool, 'error': str (if failed) } Examples: move_mouse(100, 200) # Moves to absolute x=100, y=200 move_mouse(10, 10, relative=True) # Moves 10px right and down |
| click_mouseA | Simulate left mouse click at current position. Returns: dict: { 'success': bool, 'error': str (if failed) } Example: click_mouse() # Clicks at current cursor position |
| drag_mouseB | Perform drag operation between coordinates. Args: x1, y1: Start position x2, y2: End position Returns: dict: { 'success': bool, 'error': str (if failed) } Example: drag_mouse(100, 100, 200, 200) # Drags from (100,100) to (200,200) |
| scroll_mouseB | Scroll vertically (positive=up, negative=down). Note: Each unit represents one notch on the scroll wheel (120 units = high-definition scroll). Typical values range from 2-3 to 5-10 for normal scrolling. |
| capture_screenshotC | Capture the screen, with measurement rulers drawn on the result. |
| compare_imagesC | Compare two images using a VLM. Requires a configured VLM provider. |
| analyze_screenshotB | Analyze a screenshot with a VLM. Requires a configured VLM provider. |
| execute_actionA | Execute system actions with chaining support. Handles both single actions and chained sequences. Args: action: Action string in format: Single: "prefix:params" (e.g. "click:100,200") Chain: "chain:action1;action2" (e.g. "chain:click:100,200;type:hello") Supported Actions: type:text - Type text press:key - Press key click/click: - Click at current position (both formats supported) move_to:x,y - Move to absolute coordinates (default) move_to:rel:x,y - Move relative to current position drag:x1,y1:x2,y2 - Drag between points scroll:amount - Vertical scroll (positive=up, negative=down) Note: Each unit = 1 scroll notch (120 = high-def scroll). Typical: 15-120. scroll:horizontal:amount - Horizontal scroll Note: Each unit = 1 scroll notch (120 = high-def scroll). Typical: 15-120. Returns: dict: {'success': bool, 'error': str} Example: execute_action("click:100,200") execute_action("chain:click:100,200;type:hello;press:Enter") |
| capture_and_analyzeB | Capture then analyze the screen. Requires a configured VLM provider. |
| describe_environmentA | Report which backends this machine offers, and which were selected. Call this first when a capture or an input action fails: it says what is installed, what the compositor advertises, and what that adds up to. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
The individual mouse tools (move_mouse, click_mouse, drag_mouse, scroll_mouse) are distinct, but execute_action duplicates all of them and adds more. Descriptions hint that execute_action is for chaining, yet the boundary between simple and composite usage remains ambiguous.
All tool names use consistent snake_case with a verb_noun pattern (e.g., move_mouse, capture_screenshot, execute_action). The only minor deviation is capture_and_analyze, but it still follows the same convention.
Ten tools is well within the ideal range for a desktop automation server. Each tool covers a distinct operation or a useful composite, and the count does not feel bloated.
The surface covers mouse control, screenshots, VLM analysis, and environment introspection. Keyboard actions are only available through execute_action, which is a minor gap, but core workflows are supported.