Skip to main content
Glama

Related Servers

Alternatives to hypruse

No user-submitted related servers found.

    Related Servers

    • A
      license
      Not graded
      quality
      C
      maintenance
      An MCP server that enables AI agents to observe and control a Hyprland Wayland desktop using screenshots, accessibility trees, native virtual pointer/keyboard input, and window management. It allows clicking, typing, scrolling, launching apps, and waiting for UI state without uinput, root, or portals, with an optional isolated nested desktop.
      MIT
    • A
      license
      A
      quality
      D
      maintenance
      An MCP server for Hyprland desktop automation that allows AI assistants to see the screen, control mouse and keyboard, and manage windows using native Wayland tools. It integrates OCR for text-based interaction and supports complex multi-monitor setups with pixel-accurate coordinate mapping.
      27
      6
      MIT
    • A
      license
      A
      quality
      B
      maintenance
      Enables AI agents to control Hyprland desktops via MCP, including pointer/keyboard input, screenshots, launching apps, and natural-language window targeting using a local decision model.
      14
      1
      MIT
    • A
      license
      Not graded
      quality
      B
      maintenance
      An MCP server that controls native Wayland windows on KDE Plasma from an AI agent, enabling window listing, screenshots, clicks, typing, and more.
      18 PyPI
      MIT
    • A
      license
      Not graded
      quality
      C
      maintenance
      MCP server for controlling Hyprland Wayland compositor: screen capture, mouse/keyboard injection, and automation via native Hyprland IPC and wlr protocols.
      MIT
    • A
      license
      Not graded
      quality
      C
      maintenance
      MCP server for controlling Linux desktops over Wayland, enabling AI agents to perform mouse, keyboard, window, and screenshot operations on Fedora KDE Plasma.
      AGPL 3.0

    TDQS

    A4.5/5.0

    Scored across 14 tools

    Disambiguation5/5

    Each tool has a crisply distinct role, and the descriptions actively delineate boundaries (pointer vs click_ui, keyboard vs use_bind vs hypr, screenshot vs zoom vs marks vs ui). Overlapping-seeming tools like screenshot/zoom/marks and ui/click_ui are separated by explicit coarse-to-fine vs accessibility vs annotated-capture semantics. An agent can reliably pick the right tool.

    Naming Consistency4/5

    All names are lowercase single tokens with underscore used consistently for multi-word tools (wait_for, click_ui, use_bind), so formatting is uniform. The only wobble is semantic: some names are nouns (desktop, marks, binds, pointer) and others verbs (launch, zoom), which is a minor deviation from a single predictable pattern.

    Tool Count5/5

    14 tools is well within the ideal 3-15 range and each earns its place: perception (desktop, screenshot, zoom, ui, marks), input (pointer, keyboard, click_ui), orchestration (wait_for, sequence), and system control (hypr, launch, binds, use_bind) with no filler.

    Completeness5/5

    The desktop-automation surface is essentially full: snapshot, capture at two fidelities, accessibility read/annotate, mouse, keyboard, background-window targeting, event waiting, window/workspace IPC, app launch, keybind discovery and replay, plus a batch runner. It even documents fallback paths (vision when no a11y tree) and hard limits (locked session, auth dialogs), leaving no obvious dead ends.

    Maintenance

    ActivityActive
    ResponsivenessWithin a week