What can you do with this server?

This server enables AI assistants like Claude to automate and test Tauri desktop applications through the Model Context Protocol (MCP). App Lifecycle Management * Check app status (app_status) * Launch the app (launch_app) — via pnpm tauri dev, with options for timeout, readiness wait, Cargo features, and devtools * Stop the app (stop_app) Window Management * List all open windows with labels, titles, and focus state (list_windows) * Focus a specific window by label (focus_window) UI Interaction * Capture the accessibility tree to get element references (snapshot) * Click elements by reference number or CSS selector (click) * Fill input fields by reference or selector (fill) * Simulate keyboard key presses (press_key) * Navigate the webview to a URL (navigate) * Execute arbitrary JavaScript in the webview (evaluate_script) * Take screenshots (screenshot) Observability * Retrieve and filter unified app logs — build, runtime, console, network — with optional limit and auto-clear (get_logs) * Retrieve recent app restart/HMR reload events, including the files that triggered them (get_restart_events) All interaction and observability tools accept an optional window parameter to target a specific window by label, defaulting to the currently focused window.

Which integrations are available for this server?

Enables automated testing and interaction with Tauri desktop applications, providing tools to launch and stop apps, capture screenshots, navigate URLs, retrieve logs, and automate UI actions like clicking or filling input fields.

How do I use tauri-plugin-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@tauri-plugin-mcp launch the app and take a screenshot of the landing page" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ja ko ru zh

tauri-plugin-mcp

by DaveDev42

Overview Schema Related Servers Score Discussions

TypeScript

Local

tauri-plugin-mcp

Cross-platform Tauri test automation plugin via MCP (Model Context Protocol).

Enables AI assistants like Claude to interact with your Tauri desktop app for testing and automation.

Claude Code Plugin

This repo doubles as a Claude Code plugin. Three steps to a fully working setup:

1. Add the marketplace and install the plugin

/plugin marketplace add DaveDev42/tauri-plugin-mcp
/plugin install tauri-mcp

During installation you'll be prompted for:

Tauri app directory: path relative to project root (e.g. . for single-app repos, apps/desktop for monorepos).

2. Run the installer command

/tauri-mcp:install

This auto-edits your Tauri project: Cargo.toml, src-tauri/src/lib.rs, capabilities, package.json, the frontend entry (main.tsx/main.ts), and .gitignore. Every write is previewed as a diff and requires your confirmation first.

3. Restart Claude Code

The tauri-mcp MCP server registers on restart. Verify with /mcp — it should show tauri-mcp as connected. You can now call start_session, snapshot, click, etc.

Why restart?

MCP servers are registered at Claude Code startup. Installing the plugin or changing tauri_app_dir both require a restart to take effect.

What the plugin ships

The MCP server ships as a self-contained single-file bundle (packages/tauri-mcp/dist/index.js) with all dependencies inlined — no node_modules needed on the target machine, so installation works identically on macOS, Linux, and Windows.

What's included:

Component	Description
MCP Server	Self-contained `tauri-mcp` bundle (14 tools for app lifecycle, UI interaction, screenshots, logging)
`/tauri-mcp:install` command	One-shot installer that edits your Tauri project to wire up the plugin
`tauri-qa` skill	QA orchestration — prepares test scenarios, delegates to QA agent, validates results
`tauri-debug` skill	Diagnostic decision trees for common MCP session issues
`qa-tester` agent	Testing agent (haiku) that executes test scenarios using MCP tools
QA validation hook	Verifies QA PASS results include actual tool call evidence

Related MCP server: MCP Server Tauri

Features

Cross-platform: Windows (Named Pipes) + macOS/Linux (Unix Sockets)
No CDP dependency: Works on all WebView backends including macOS WKWebView
MCP integration: Direct integration with Claude Code and other MCP clients
Multi-window support: Target any window by label; auto bridge injection
Unified logging: Build, runtime, console, and network logs with filtering
Dynamic port allocation: Automatic random port assignment to avoid conflicts

Prerequisites

Node.js >= 18
Tauri v2.x
pnpm (recommended) or npm
Rust with cargo

Quick Start

Add Rust plugin to src-tauri/Cargo.toml
Install npm package: pnpm add github:DaveDev42/tauri-plugin-mcp#main
Register plugin in src-tauri/src/lib.rs
Add mcp:default permission
Initialize bridge in main.tsx
Create .mcp.json for Claude Code

Installation

1. Rust Plugin (src-tauri/Cargo.toml)

[dependencies]
tauri-plugin-mcp = { git = "https://github.com/DaveDev42/tauri-plugin-mcp" }

2. Frontend API (package.json)

pnpm add github:DaveDev42/tauri-plugin-mcp#main

3. MCP Server

The MCP server binary (tauri-mcp) is automatically available after installation. No additional setup required.

Setup

1. Register the plugin (src-tauri/src/lib.rs)

pub fn run() {
    tauri::Builder::default()
        .plugin(tauri_plugin_mcp::init())
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

2. Add permissions

Option A: In tauri.conf.json or config/*.json5 (recommended)

{
  "security": {
    "capabilities": [{
      "identifier": "main-capability",
      "windows": ["main"],
      "permissions": ["core:default", "mcp:default"]
    }]
  }
}

Option B: Separate file (src-tauri/capabilities/default.json)

{
  "$schema": "../gen/schemas/desktop-schema.json",
  "identifier": "default",
  "windows": ["main"],
  "permissions": ["core:default", "mcp:default"]
}

3. Initialize the bridge (main.tsx)

// Initialize MCP bridge for E2E testing (dev mode only)
if (import.meta.env.DEV) {
  import('tauri-plugin-mcp').then(({ initMcpBridge }) => {
    initMcpBridge().catch(err => {
      console.warn('[MCP] Bridge initialization failed:', err);
    });
  });
}

Production-Safe Setup (Optional Dependency)

The basic setup above includes MCP in all builds. For production apps, you likely want MCP only in development and completely stripped from release binaries.

This approach uses Cargo's optional dependency feature so the plugin is compiled in only when explicitly requested.

1. Cargo optional dependency (src-tauri/Cargo.toml)

[features]
default = []
dev-tools = ["dep:tauri-plugin-mcp"]

[dependencies]
tauri-plugin-mcp = { git = "https://github.com/DaveDev42/tauri-plugin-mcp", optional = true }

2. Conditional plugin registration (src-tauri/src/lib.rs)

pub fn run() {
    let mut builder = tauri::Builder::default();

    #[cfg(feature = "dev-tools")]
    {
        builder = builder.plugin(tauri_plugin_mcp::init());
    }

    builder
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

3. Capabilities file split

Separate mcp:default into its own capability file so it can be toggled at build time.

capabilities/default.json — always active, no MCP permission:

{
  "$schema": "../gen/schemas/desktop-schema.json",
  "identifier": "default",
  "windows": ["main"],
  "permissions": ["core:default"]
}

capabilities/.dev-tools.json.disabled — MCP permission template (git-tracked):

{
  "$schema": "../gen/schemas/desktop-schema.json",
  "identifier": "dev-tools",
  "windows": ["main"],
  "permissions": ["mcp:default"]
}

capabilities/dev-tools.json — add to .gitignore (generated at build time):

# Dev-tools capability (generated from .disabled at build time)
src-tauri/capabilities/dev-tools.json

4. build.rs — conditional capabilities management

build.rs copies the template into place when the feature is enabled, and removes it otherwise:

fn main() {
    let dev_tools_cap = std::path::Path::new("capabilities/dev-tools.json");
    let source_path = std::path::Path::new("capabilities/.dev-tools.json.disabled");

    if std::env::var("CARGO_FEATURE_DEV_TOOLS").is_ok() {
        // Copy .disabled → active (skip if already identical to avoid rebuild churn)
        let should_copy = if dev_tools_cap.exists() {
            std::fs::read(source_path).ok() != std::fs::read(dev_tools_cap).ok()
        } else {
            true
        };
        if should_copy {
            std::fs::copy(source_path, dev_tools_cap)
                .expect("Failed to copy dev-tools capability file");
        }
    } else if dev_tools_cap.exists() {
        std::fs::remove_file(dev_tools_cap).ok();
    }

    tauri_build::try_build(
        tauri_build::Attributes::default()
    ).expect("Failed to build tauri");
}

5. Dev script (package.json)

{
  "scripts": {
    "dev": "tauri dev --features dev-tools"
  }
}

Now pnpm dev enables MCP, while tauri build (without the feature) produces a clean release with zero MCP code.

Note: The frontend bridge guard (import.meta.env.DEV) from the basic setup still applies — it prevents the bridge from initializing even if the plugin were somehow present at runtime.

MCP Server Configuration

Note: If you installed the Claude Code Plugin, the MCP server is already configured automatically. The plugin prompts for the Tauri app directory during installation. This section is for manual setup without the plugin.

Add to .mcp.json in your project root:

{
  "mcpServers": {
    "tauri-mcp": {
      "command": "npx",
      "args": ["tauri-mcp"],
      "env": {
        "TAURI_APP_DIR": "."
      }
    }
  }
}

Note: pnpm users can also use pnpx tauri-mcp or pnpm exec tauri-mcp.

Monorepo Configuration

If the Tauri app is in a subdirectory (e.g., apps/desktop), set TAURI_APP_DIR:

{
  "mcpServers": {
    "tauri-mcp": {
      "command": "npx",
      "args": ["tauri-mcp"],
      "env": {
        "TAURI_APP_DIR": "./apps/desktop"
      }
    }
  }
}

Multiple Tauri Apps

For monorepos with multiple Tauri apps, run a separate MCP server instance per app:

{
  "mcpServers": {
    "tauri-desktop": {
      "command": "npx",
      "args": ["tauri-mcp"],
      "env": { "TAURI_APP_DIR": "./apps/desktop" }
    },
    "tauri-kiosk": {
      "command": "npx",
      "args": ["tauri-mcp"],
      "env": { "TAURI_APP_DIR": "./apps/kiosk" }
    }
  }
}

Tools are namespaced by server name: mcp__tauri-desktop__snapshot, mcp__tauri-kiosk__snapshot, etc.

Available Tools

Session Lifecycle

Tool	Parameters	Description
`get_session_status`	`probe_bridge?: boolean`	Check session (app) status; with `probe_bridge: true`, includes per-window bridge health
`start_session`	`wait_for_ready?: boolean`, `timeout_secs?: number`, `features?: string[]`, `devtools?: boolean`	Start session (launch Tauri app via `pnpm tauri dev`)
`stop_session`	-	Stop session (kill app process tree)

Window Management

Tool	Parameters	Description
`list_windows`	-	List all open windows with labels, titles, focus state, and bridge status
`focus_window`	`window: string`	Focus a specific window by label

Interaction

All interaction tools accept an optional window parameter to target a specific window (defaults to focused window).

Tool	Parameters	Description
`snapshot`	`window?`	Get accessibility tree with ref numbers for `click`/`fill`
`click`	`ref?: number`, `selector?: string`, `window?`	Click element by ref or CSS selector
`fill`	`ref?: number`, `selector?: string`, `value: string`, `window?`	Fill input field
`press_key`	`key: string`, `window?`	Press keyboard key (e.g., "Enter", "Tab")
`navigate`	`url: string`, `window?`	Navigate to URL
`screenshot`	`window?`	Take screenshot via native OS capture
`evaluate_script`	`script: string`, `window?`	Execute JavaScript in webview

Observability

Tool	Parameters	Description
`get_logs`	`filter?: string[]`, `limit?: number`, `clear?: boolean`, `window?`	Unified log access (build, runtime, console, network) with source/level filtering
`get_restart_events`	`limit?: number`, `clear?: boolean`, `window?`	Get recent app restart/reload events with triggering files

Using `features` parameter

To launch with Cargo features:

start_session({ features: ["my_feature"] })

This runs: pnpm tauri dev --features my_feature

Usage Example

Typical testing workflow:

1. start_session({ timeout_secs: 120 })
2. snapshot()           # Get element refs
3. click({ ref: 5 })    # Click button by ref
4. fill({ selector: "input[name='email']", value: "test@example.com" })
5. screenshot()         # Verify result
6. stop_session()

How It Works

Claude Code <-> MCP Server <-> Socket <-> Tauri Plugin <-> JS Bridge <-> Your App

Rust Plugin creates IPC server (Unix socket or Windows named pipe)
MCP Server connects to IPC and exposes tools to Claude
JS Bridge (initMcpBridge()) enables DOM operations in WebView

Socket Paths

Unix: {project_root}/.tauri-mcp.sock
Windows: \\.\pipe\tauri-mcp-{hash} (hash derived from project path)

TCP Transport (remote access via SSH tunnel)

By default the plugin communicates over a local named pipe (Windows) or Unix socket (macOS/Linux). Named pipes and Unix sockets are machine-local — they cannot cross a network boundary. Use the optional TCP transport when the Tauri app runs on a different machine than Claude Code (e.g. a kiosk PC driven remotely, or a CI runner).

When TAURI_MCP_TCP is unset, behavior is byte-for-byte unchanged — the existing pipe/socket is the only transport.

App side (Rust plugin)

Set TAURI_MCP_TCP when launching the app. The plugin binds a TCP listener in addition to the existing pipe/socket (the pipe is never removed).

TAURI_MCP_TCP=127.0.0.1:19878   # bind on loopback only (recommended — reach via SSH tunnel)
TAURI_MCP_TCP=19878              # shorthand — same as 127.0.0.1:19878
TAURI_MCP_TCP=0.0.0.0:19878     # bind all interfaces (only if network is fully trusted)

The plugin logs the bound address on startup:

[tauri-plugin-mcp] TCP transport listening on 127.0.0.1:19878

MCP server side (Node)

Set the same TAURI_MCP_TCP env on the MCP server process. It dials TCP instead of the local pipe/socket and skips all local pipe discovery:

{
  "mcpServers": {
    "tauri-mcp": {
      "command": "npx",
      "args": ["tauri-mcp"],
      "env": {
        "TAURI_APP_DIR": ".",
        "TAURI_MCP_TCP": "127.0.0.1:19878"
      }
    }
  }
}

Worked example — remote kiosk via SSH tunnel

On the remote machine (kiosk app running with TCP transport):

TAURI_MCP_TCP=127.0.0.1:19878 pnpm tauri dev
# → [tauri-plugin-mcp] TCP transport listening on 127.0.0.1:19878

On the dev machine (forward the port via SSH):

ssh -L 19878:127.0.0.1:19878 kiosk-host

MCP server .mcp.json (dev machine, connects through the tunnel):

{
  "mcpServers": {
    "tauri-mcp": {
      "command": "npx",
      "args": ["tauri-mcp"],
      "env": {
        "TAURI_APP_DIR": "/path/to/local/project",
        "TAURI_MCP_TCP": "127.0.0.1:19878"
      }
    }
  }
}

start_session / stop_session are not available in TCP mode (the MCP server cannot launch or kill a process on the remote machine). Use the interaction and observability tools (snapshot, click, get_logs, etc.) to drive the already-running app.

Troubleshooting

"MCP bridge not initialized"

The JS bridge isn't running. Check:

initMcpBridge() is called in your frontend code
App is running in dev mode (import.meta.env.DEV)
Check browser console for initialization errors

Socket connection failed

Ensure the app is running (start_session first)
On Windows, check pipe path in logs: [tauri-plugin-mcp] full_path: \\.\pipe\tauri-mcp-XXXXX
On Unix, check if .tauri-mcp.sock exists in project root

App launch timeout

Increase timeout_secs (default: 60)
Check if pnpm tauri dev works manually
Look for build errors in terminal output

snapshot returns empty

Wait for app to fully load (use wait_for_ready: true)
Check if bridge initialized (look for [MCP] logs in console)

Development

After cloning, pnpm install automatically configures git hooks and builds the project.

The dist/ directories are committed to the repo so that git-based installs (pnpm add github:...) work without a build step. A pre-commit hook verifies that dist/ stays in sync with TypeScript sources — if the hook blocks your commit, run:

pnpm build
git add packages/*/dist/

Then retry your commit.

License

MIT OR Apache-2.0

Available Tools

14 tools

clickC

Click element by ref or selector

ParametersJSON Schema

Name	Required	Description
`ref`	No	Ref from snapshot
`selector`	No	CSS selector
`window`	No	Window label (default: focused window)

TDQS

C2.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fails to disclose behavioral traits such as whether the click waits for element visibility, triggers navigation, or handles errors. It adds no behavioral context beyond the basic action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the action, but it is overly minimal. It sacrifices completeness for brevity, lacking sufficient detail for a three-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description does not provide enough contextual completeness. It omits behavioral details, expected side effects, and error handling, which are important for correct tool usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage with descriptions for all parameters. The description adds no extra semantics beyond the schema's details, achieving baseline adequacy.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'click' and the resource 'element', and specifies two methods of identification (ref or selector). It effectively distinguishes from sibling tools like fill or press_key, but could be more explicit about simulating a mouse click.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 press_key or evaluate_script. There is no mention of prerequisites, context, or exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

evaluate_scriptC

Run JS in webview

ParametersJSON Schema

Name	Required	Description	Default
`script`	Yes	JS code
`window`	No	Window label (default: focused window)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits. It only says 'Run JS' without indicating if the script is sandboxed, whether it returns results, or any 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, front-loaded with the key action. It is efficient but could benefit from additional context without being verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a script execution tool with two parameters and no output schema, the description is incomplete. It does not explain return values, error behavior, or how the script interacts with the webview environment.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, but the description adds no value beyond the schema: 'JS code' and 'Window label' are already in the input schema. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Run JS in webview' clearly states the action and target resource. It distinguishes from sibling browser tools like click and navigate by specifying script execution, but lacks detail on what 'webview' refers to.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 click or fill. There is no mention of prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

fillC

Fill input by ref or selector

ParametersJSON Schema

Name	Required	Description
`ref`	No	Ref from snapshot
`selector`	No	CSS selector
`value`	Yes	Value
`window`	No	Window label (default: focused window)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description does not disclose behavioral traits such as whether it clears the existing value, supports file inputs, or handles non-input elements. The brief description leaves significant ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise (5 words) and front-loaded. However, it may be too brief, sacrificing necessary detail for brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and lack of output schema, the description is incomplete: it does not specify the behavior on different input types, whether it simulates typing or sets value programmatically, or error scenarios.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for all 4 parameters. The description adds 'by ref or selector' to clarify parameter usage, but does not add further semantic meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'fill' and resource 'input', and specifies the method 'by ref or selector'. It is clear but does not differentiate from siblings like 'click' or 'press_key'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 (e.g., 'press_key' for key presses, 'click' for clicks). No context or exclusions provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

focus_windowB

Focus a specific window by label

ParametersJSON Schema

Name	Required	Description	Default
`window`	Yes	Window label to focus

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It fails to disclose what 'focus' entails (e.g., bring to front, activate window) or behavior on missing label.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no fluff, front-loaded. Score would be 5 if it contained more behavioral detail without being verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, and description lacks detail on return values, error cases, or prerequisites. Minimal for a tool with no annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a clear parameter description. Tool description adds no extra meaning beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb 'focus', the resource 'window', and the qualifier 'by label'. It distinguishes the tool from siblings like 'list_windows' and 'click'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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, no preconditions or exclusions provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_logsC

Get application logs with filtering. Filters can be combined (e.g., ["build", "error"] for build errors only).

ParametersJSON Schema

Name	Required	Description
`filter`	No	Filters to apply (empty = all logs)
`limit`	No	Max entries
`clear`	No	Clear logs after reading
`window`	No	Window label for frontend logs (default: focused window)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose all behavioral traits. It mentions filter combination but omits the clear parameter's destructive nature and window parameter's scope. Key behaviors remain undocumented.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: one sentence plus a helpful example. No wasted words, but could be better structured (e.g., bullet points). Still effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite 4 parameters and no output schema, the description only covers filter semantics. It does not explain the return format, window parameter, clear effect, or limitations. Incomplete for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (baseline 3). The tool description adds an example for filter combination, clarifying that filters can be combined, though the case of a string type with array-like example may cause confusion. Minimal value added beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get application logs' as the verb+resource, and adds filtering details. However, it could be more specific about the log source (e.g., browser console logs) to fully distinguish from sibling tools like get_restart_events.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 (e.g., evaluate_script, screenshot). The description only explains filtering, not the broader context of log retrieval use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_restart_eventsA

Get recent app restart/reload events with the files that triggered them. Includes Rust rebuilds (backend) and HMR updates (frontend).

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max events
`clear`	No	Clear events after reading
`window`	No	Window label for frontend HMR events (default: focused window)

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It partially discloses what events are included but fails to mention the destructive nature of the 'clear' parameter or side effects. The description is neutral but could be more explicit about read-only vs modifying behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the action and scope, no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, so description should explain return values. It mentions events include files but not the structure. Also missing context on parameter interactions (e.g., clear, window) beyond schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds context about event types but does not enhance parameter meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves app restart/reload events, specifies it includes Rust rebuilds and HMR updates, and uses a specific verb 'Get' with a resource, distinguishing it from siblings like get_logs or get_session_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool vs alternatives (e.g., get_logs), nor does it mention when not to use it or any prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_session_statusA

Check session (app) status. Use probe_bridge to verify bridge health per window.

ParametersJSON Schema

Name	Required	Description	Default
`probe_bridge`	No	Actively probe bridge health per window (adds latency)

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the full burden. It only mentions that probe_bridge adds latency, but does not disclose behavioral traits of this tool itself (e.g., read-only, latency, destructions). The description is too brief to offer adequate transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is exceptionally concise—two short sentences—with no unnecessary words. Every sentence serves a purpose: stating the tool's function and directing to an alternative for a specific use case.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and only one parameter, the description is minimally adequate. It states the purpose and references an alternative, but lacks details on return values, scope of 'session status', or how it fits with other tools. For a tool with 12 siblings, more completenss would help.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with one parameter described as 'Actively probe bridge health per window (adds latency)'. The description does not add extra meaning beyond the schema, so it meets the baseline 3 without exceeding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Check session (app) status' as a specific verb+resource. It further distinguishes from the sibling 'probe_bridge' by directing to use that tool for verifying bridge health per window, avoiding confusion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides limited guidance: it tells users to use 'probe_bridge' for bridge health verification, implying this tool is for general session status. However, it does not specify when to choose this over other siblings like get_logs or get_restart_events, leaving some ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_windowsA

List all open windows with their labels, titles, and focus state

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description accurately conveys a read-only operation with no side effects. It is straightforward but could mention if any special permissions or constraints apply.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no extraneous information. Every word adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the tool's purpose and output fields (labels, titles, focus state). Missing details like ordering or whether minimized windows are included, but acceptable for a simple list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, and the description correctly omits parameter details. According to guidelines, zero parameters baseline is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists open windows and specifies the information returned (labels, titles, focus state). It distinguishes from sibling tools like focus_window, which performs a different action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage (when you need to see current windows) but does not explicitly state when to use or not use this tool, nor does it mention alternatives among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

navigateC

Navigate to URL

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	URL
`window`	No	Window label (default: focused window)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description does not disclose behavioral traits such as whether navigation waits for page load, whether it replaces the current document, or any security/permission requirements. This is insufficient for an agent to understand 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise (4 words) and directly states the primary action. It is front-loaded with the verb 'Navigate' and the resource 'URL', making it efficient. However, it could benefit from a slightly more structured explanation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and sparse annotations, the description fails to cover important context such as return behavior (e.g., does it return a success status?), error handling, or session requirements. This is incomplete for a tool that changes application state.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for both parameters ('URL' and 'Window label'). The description adds no additional meaning beyond what the schema already provides, so the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Navigate') and the resource ('URL'), making the tool's purpose immediately understandable. It is distinct from siblings like 'click' or 'fill' which operate on elements, not URLs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives (e.g., when to use 'navigate' versus 'click' on a link). No context about prerequisites like requiring an active session is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

press_keyD

Press key

ParametersJSON Schema

Name	Required	Description	Default
`key`	Yes	Key name
`window`	No	Window label (default: focused window)

TDQS

D1.9/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description offers no behavioral information such as whether the press is momentary, if it supports key combinations, or what happens on failure. The agent is left to infer all 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.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

While short, the description is under-specified. It does not earn its place as it adds no information beyond the tool name. It is not appropriately sized for the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the two parameters, no output schema, and no annotations, the description is severely incomplete. It fails to explain the tool's behavior, return value, or error handling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides for 'key' and 'window'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description 'Press key' is essentially a tautology of the tool name 'press_key'. It does not specify what kind of key press (e.g., single key, combination) or provide any distinguishing detail from sibling tools like 'click' or 'fill'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives. The description does not mention typical scenarios (e.g., keyboard simulation) or exclude cases where 'click' or 'fill' might be more appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

screenshotC

Take screenshot

ParametersJSON Schema

Name	Required	Description	Default
`window`	No	Window label (default: focused window)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavior. It only states the action without explaining output, side effects, or required permissions. 'Take screenshot' is too vague for an agent to understand the tool's full impact.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise at two words, with no wasted text. However, it may be too brief for optimal clarity, though it earns a high score for lack of verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema or annotations, and the presence of a potentially similar sibling (snapshot), the description is insufficiently complete. It omits return value, side effects, and how it differs from snapshot.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single parameter, so the description adds no extra meaning beyond what the schema already provides (window label). Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Take screenshot' clearly states the action and resource, but does not differentiate from the sibling tool 'snapshot', which may have overlapping functionality.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 like snapshot, nor are there any exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

snapshotA

Get accessibility tree (returns ref numbers for click/fill)

ParametersJSON Schema

Name	Required	Description	Default
`window`	No	Window label (default: focused window)

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description mentions the return value (ref numbers) and hints at read-only nature, but does not disclose error conditions, effects, or permissions. Without annotations, this is adequate but not thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that conveys the core functionality without extraneous words. It is efficient and scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one optional parameter and no output schema, the description adequately covers what it does and what it returns. It could mention preconditions or errors, but remains mostly sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter 'window' is fully described in the input schema. The description adds no additional information about parameter usage or defaults, so it meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'Get accessibility tree' and its output 'returns ref numbers for click/fill', which distinguishes it from sibling tools like click and fill. It is specific about the resource and purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use before actions like click or fill, but does not explicitly state when to use it or provide alternatives. No comparison with siblings is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

start_sessionC

Start session (launch Tauri app)

ParametersJSON Schema

Name	Required	Description
`wait_for_ready`	No	Wait for ready
`timeout_secs`	No	Timeout seconds
`features`	No	Cargo features to enable
`devtools`	No	Open devtools on launch

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits. It only says 'launch Tauri app', missing critical details like whether the call blocks until the app is ready, if it returns a session ID, or what happens on failure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with no wasted words. The parenthetical adds clarity. Could be slightly more informative without losing conciseness, but it is not overly terse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool that launches an application, the description lacks information about return values, error states, expected duration, and side effects. No output schema, so description should cover these aspects.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so parameters are documented. However, the tool description adds no meaning beyond the schema; for example, it doesn't explain how 'wait_for_ready' interacts with 'timeout_secs'. Baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Start') and the resource ('session'), and includes a parenthetical explanation ('launch Tauri app') that distinguishes it from siblings like 'stop_session' and 'get_session_status'. However, 'session' could be more specific about what kind of session.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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. For instance, it doesn't explain whether it should be called before other tools, if there are prerequisites, or when 'stop_session' is needed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

stop_sessionB

Stop session (kill app)

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It only says 'kill app' but does not disclose whether state is saved, if confirmation is required, or any side effects. Minimal behavioral insight.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is a single efficient phrase with no unnecessary words. However, it could be slightly more descriptive without adding length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description is too minimal for a mutation tool. It lacks context on how the session termination affects the application state or subsequent actions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist and schema coverage is 100%, so the baseline is 3. The description adds no parameter info beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the action 'stop session' with the parenthetical '(kill app)' emphasizing termination. It directly contrasts with sibling tools like start_session and get_session_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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 such as get_session_status or focus_window. Usage is implied by the name but not clarified.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv0.3.6May 6, 2026
- Removedapp_status
- Addedget_session_status
- Removedlaunch_app
- Addedstart_session
- Removedstop_app
- Addedstop_session
14 tool updatesv0.1.0Feb 21, 2026
- First observedapp_status
- First observedclick
- First observedevaluate_script
- First observedfill
- First observedfocus_window
- First observedget_logs
- First observedget_restart_events
- First observedlaunch_app
- First observedlist_windows
- First observednavigate
- First observedpress_key
- First observedscreenshot
- First observedsnapshot
- First observedstop_app

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0

Disambiguation5/5

Each tool targets a distinct action or information source: UI interactions (click, fill, press_key), scripting (evaluate_script), navigation (navigate), visual capture (screenshot), accessibility (snapshot), window management (list_windows, focus_window), session lifecycle (start/stop_session), and diagnostics (get_logs, get_restart_events, get_session_status). No two tools have overlapping purposes.

Naming Consistency5/5

All tool names follow a clear verb_noun pattern using lowercase with underscores (e.g., get_logs, focus_window, start_session). Even single-word names like click, fill, navigate are consistent with the imperative style. No mixed conventions or inconsistent verbs.

Tool Count5/5

14 tools is well-scoped for a Tauri testing/MCP server. It covers all major aspects: session control, window management, UI interaction, scripting, diagnostics, and capture. The count is neither too sparse (missing essential features) nor bloated.

Completeness5/5

The tool surface covers the full lifecycle of a Tauri app test: start/stop sessions, manage windows, interact via clicks/keys/scripts, navigate, capture screenshots and accessibility trees, and retrieve logs/events. No obvious gaps for typical automation tasks, making it a self-contained toolset.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216
IFTTT MCP serverOAuth
com.ifttt
Automate 1,000+ services from any MCP-compatible AI agent: build Applets, run actions and queries.
App Automation
1
mobilerun
io.github.droidrun
Control real Android and iOS devices with LLM agents — tap, swipe, type, automate flows.
Testing & QA Tools App Automation
38,854

Related MCP Servers

MCP Tauri Automation
Testing & QA Tools App Automation
Radek44
A
license
A
quality
C
maintenance
Enables AI-driven testing and automation of Tauri desktop applications through natural language, allowing users to interact with UI elements, capture screenshots, execute commands, and test application flows without manual clicking or complex scripts.
Updated 2 months ago (2026-07-11 21:06 UTC)
9
7
MIT
MCP Server Tauri
Developer Tools App Automation Testing & QA Tools
hypothesi
A
license
A
quality
A
maintenance
Enables AI assistants to build, test, and debug Tauri v2 applications with UI automation, IPC monitoring, mobile device management, and real-time access to screenshots, DOM state, and console logs.
Updated 8 days ago (2026-08-28 22:52 UTC)
20
297
MIT
tauri-mcp
App Automation Developer Tools OS Automation
DonsWayo
A
license
Not graded
quality
D
maintenance
A Tauri plugin that enables AI agents to interact with Tauri applications through screenshots, DOM inspection, and input simulation via the Model Context Protocol. It allows agents to perform actions like clicking, typing, and executing JavaScript within the application's webview context.
Updated 7 months ago (2026-02-21 10:27 UTC)
897
1
MIT
Tauri MCP Server
Developer Tools Testing & QA Tools App Automation
delorenj
A
license
Not graded
quality
D
maintenance
Enables AI agents to interact with and debug Tauri desktop applications, providing tools for window management, user input simulation, and storage operations.
Updated 10 months ago (2025-10-30 20:38 UTC)
897
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/DaveDev42/tauri-plugin-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

tauri-plugin-mcp

Claude Code Plugin

Why restart?

What the plugin ships

Features

Prerequisites

Quick Start

Installation

1. Rust Plugin (src-tauri/Cargo.toml)

2. Frontend API (package.json)

3. MCP Server

Setup

1. Register the plugin (src-tauri/src/lib.rs)

2. Add permissions

3. Initialize the bridge (main.tsx)

Production-Safe Setup (Optional Dependency)

1. Cargo optional dependency (src-tauri/Cargo.toml)

2. Conditional plugin registration (src-tauri/src/lib.rs)

3. Capabilities file split

4. build.rs — conditional capabilities management

5. Dev script (package.json)

MCP Server Configuration

Monorepo Configuration

Multiple Tauri Apps

Available Tools

Session Lifecycle

Window Management

Interaction

Observability

Using features parameter

Usage Example

How It Works

Socket Paths

TCP Transport (remote access via SSH tunnel)

App side (Rust plugin)

MCP server side (Node)

Worked example — remote kiosk via SSH tunnel

Troubleshooting

"MCP bridge not initialized"

Socket connection failed

App launch timeout

snapshot returns empty

Development

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Using `features` parameter