Skip to main content
Glama
Wayland MCP Server
by kurojs

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
VLM_MODELNoModel identifier. Defaults: 'qwen/qwen2.5-vl-72b-instruct:free' for OpenRouter or 'gemini-2.5-flash' for Gemini.
VLM_PROVIDERNoVision provider: 'openrouter' or 'gemini'openrouter
GEMINI_API_KEYNoGoogle Gemini API key
WAYLAND_DISPLAYYesDisplay identifier (e.g., wayland-0)
XDG_RUNTIME_DIRYesWayland runtime directory (e.g., /run/user/1000)
WAYLAND_MCP_PORTNoServer listen port4999
OPENROUTER_API_KEYNoOpenRouter 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

CapabilityDetails
tools
{
  "listChanged": true
}
logging
{}
prompts
{
  "listChanged": true
}
resources
{
  "subscribe": false,
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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}

Declared as a dict because that is what every code path returns. It was
annotated -> bool while returning dicts, and a strict MCP client rejects the
structured content against the declared schema, so the tool was unusable
from a conforming client.

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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.5/5.0

Scored across 10 tools

Disambiguation3/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityNo data
ResponsivenessSyncing