rust-debug-mcp
Provides tools for debugging and operating Rust Tauri applications over WebSocket, including app lifecycle management, core debugging, metrics inspection, UI automation, and more.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@rust-debug-mcpcheck connection to my Tauri app"
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.
rust-debug-mcp
A Model Context Protocol (MCP) server for debugging and operating Rust Tauri applications over WebSocket.
Table of Contents
Related MCP server: tauri-plugin-mcp
Overview
rust-debug-mcp bridges MCP clients and Tauri debug backends. It provides a single tool (tauri_debug_command) that routes commands to specialized handlers for app lifecycle operations, core debugging, metrics/task inspection, frontend actions, and UI automation.
It supports multiple target apps through configs/apps.json, including capability checks per app before command execution.
Features
Core Functionality
Multi-app registry support with per-app command capability gating
App lifecycle management (
start_app,kill_app)Core debug command forwarding through a typed WebSocket bridge
Response verbosity control (
conciseanddetailed)
Debugging & Inspection
Task/session/metrics commands for Commander-style backends
Frontend broadcast support for app-side actions
UI automation commands (
click,fill,select,type,press_key, snapshots, screenshots, wait/hover/scroll, console logs)
Reliability
Connection status checks and reconnect behavior in bridge manager
Request timeout handling for bridge calls
Ordered handler routing with clean command-to-handler resolution
Installation
Quick Setup
# Clone repository
git clone https://github.com/ruizrica/rust-debug-mcp.git
# Enter project
cd rust-debug-mcp
# Install dependencies
npm install
# Build
npm run buildInstalling in an MCP Client
Add to your MCP config (example):
{
"mcpServers": {
"tauri-debug": {
"command": "node",
"args": ["/absolute/path/to/rust-debug-mcp/dist/server.js"],
"env": {
"LOG_LEVEL": "info",
"TAURI_WS_URL": "ws://localhost:9002",
"COMMANDER_WS_URL": "ws://localhost:9002"
}
}
}
}For deeper setup and troubleshooting, see docs/RUNBOOK.md.
Usage
Starting the Server
npm run dev
# or
npm startThe server communicates over stdio and is intended to be launched by an MCP client.
Multi-App Configuration
configs/apps.json controls default app, app endpoints, and command capability sets:
{
"default": "commander",
"apps": {
"commander": {
"name": "Commander",
"wsUrl": "ws://localhost:9002",
"commands": ["all"]
},
"photon": {
"name": "Photon CLI",
"wsUrl": "ws://localhost:9847",
"commands": ["core", "ui_automation"]
}
}
}Tools API
The server exposes one MCP tool:
Tool | Description |
| Execute a debug command against a selected app ( |
Command Categories
App lifecycle:
start_app,kill_appCore:
test_connection,get_debug_mode,set_debug_mode,get_app_dir,get_logs,get_system_metrics,test_command,simple_testTask/session/metrics:
get_session_metrics,get_task_metrics,get_all_tasks,get_task,get_tasks_by_status,get_task_groups,list_windowsFrontend action:
broadcast_to_frontendUI automation:
click,fill,select,type,press_key,get_snapshot,take_screenshot,wait_for,hover,scroll,get_console_logs
For full payload details, see docs/COMMAND_REFERENCE.md.
Examples
Minimal Command
{
"command": "test_connection"
}Targeting a Specific App
{
"command": "get_debug_mode",
"app": "commander"
}UI Interaction
{
"command": "click",
"app": "photon",
"params": {
"uid": "e5"
}
}Development
Project Structure
rust-debug-mcp/
├── src/
│ ├── server.ts # MCP server entry point
│ ├── bridge-manager.ts # WebSocket bridge and manager
│ ├── app-registry.ts # Multi-app registry and capability checks
│ ├── handlers/ # Command handlers and router
│ ├── response-formatter.ts # Concise/detailed output formatter
│ └── types.ts # Type definitions
├── configs/
│ └── apps.json
├── docs/
├── tests/
├── package.json
└── tsconfig.jsonBuild
npm run buildTypecheck
npm run typecheckTesting
npm test
npm run test:unit
npm run test:integrationContributing
Contributions are welcome.
Fork the repository
Create a feature branch
Make and test your changes
Open a pull request
License
MIT
Built with TypeScript, Rust, Tauri, and MCP.
Available Tools
1 tooltauri_debug_commandA
Debug and inspect Tauri applications via WebSocket.
MULTI-APP SUPPORT: This tool can connect to any Tauri app with a debug WebSocket endpoint.
Available apps: commander, photon
Default app: commander
Use "app" parameter to specify which app to connect to
QUICK REFERENCE:
Lifecycle: start_app, kill_app
Health: test_connection, get_debug_mode
Tasks: get_task, get_tasks_by_status, get_task_metrics, get_all_tasks (Commander only)
Sessions: get_session_metrics, list_windows (Commander only)
System: get_system_metrics, get_app_dir, get_logs
Actions: broadcast_to_frontend, set_debug_mode (Commander only)
UI Automation: click, fill, select, type, press_key, get_snapshot, take_screenshot, wait_for, hover, scroll, get_console_logs
FILTERING TASKS (avoid loading all tasks): { "command": "get_task", "params": { "task_id": 123 } } { "command": "get_tasks_by_status", "params": { "status": "working" } } { "command": "get_all_tasks", "params": { "status": "pending", "limit": 20 } } { "command": "get_all_tasks", "params": { "recent_only": true } }
RESPONSE FORMAT: Add response_format: "concise" (default) or "detailed" to control verbosity.
concise: Truncates arrays to 20 items, includes metadata about truncation
detailed: Returns full data without truncation
APP LIFECYCLE COMMANDS:
"start_app": Start a Tauri application (optional: path, command, args, env, timeout, waitForConnection)
"kill_app": Kill a running Tauri application (optional: force, timeout)
CORE COMMANDS (all apps):
"test_connection": Check Tauri bridge connectivity
"get_debug_mode": Get current debug mode status
"set_debug_mode": Enable/disable debug mode (requires enabled: boolean)
"get_app_dir": Get application directory paths
"get_logs": Get recent application logs
"get_system_metrics": Get system resource metrics
"test_command": Test command execution (requires command: string)
"simple_test": Run a simple test command
COMMANDER-SPECIFIC COMMANDS:
"get_task": Get single task by ID (requires task_id: number)
"get_tasks_by_status": Get tasks filtered by status (requires status: string)
"get_all_tasks": Get tasks with optional filtering (status?, limit?, recent_only?)
"get_task_metrics": Get task count breakdown by status
"get_task_groups": Get task groups/initiatives with progress
"get_session_metrics": Get active sessions list
"list_windows": List connected WebSocket clients
"broadcast_to_frontend": Send message to frontend (requires action, payload)
UI AUTOMATION COMMANDS:
"click": Click element (requires uid: string)
"fill": Clear and fill input element (requires uid: string, value: string)
"select": Select dropdown option (requires uid: string, value: string)
"type": Type text into element (requires uid: string, text: string)
"press_key": Press keyboard key or combination (requires key: string)
"get_snapshot": Get accessibility tree snapshot (returns interactive elements with refs)
"take_screenshot": Take page screenshot (optional: full_page: boolean, path: string)
"wait_for": Wait for text or element (requires text_or_selector: string, timeout?: number)
"hover": Hover over element (requires uid: string)
"scroll": Scroll page or element (requires direction: string, amount?: number)
"get_console_logs": Get browser/frontend console messages (optional: types[], limit, includePreservedLogs)
EXAMPLES: { "command": "start_app", "app": "photon" } { "command": "start_app", "app": "photon", "params": { "command": "cargo tauri dev", "waitForConnection": true } } { "command": "kill_app", "app": "photon" } { "command": "kill_app", "app": "photon", "params": { "force": true } } { "command": "test_connection" } { "command": "test_connection", "app": "photon" } { "command": "get_task", "params": { "task_id": 42 } } { "command": "get_tasks_by_status", "params": { "status": "working" } } { "command": "get_all_tasks", "params": { "limit": 10 }, "response_format": "detailed" } { "command": "broadcast_to_frontend", "params": { "action": "execute_js", "payload": { "script": "document.title" } } } { "command": "get_snapshot" } { "command": "click", "params": { "uid": "e5" } } { "command": "fill", "params": { "uid": "e3", "value": "test@example.com" } } { "command": "take_screenshot", "params": { "full_page": true } } { "command": "get_console_logs", "params": { "types": ["error", "warn"], "limit": 50 } }
RESPONSE: Returns { success: boolean, data?: unknown, error?: string }
| Name | Required | Description | Default |
|---|---|---|---|
| app | No | Target app to debug. Available: commander, photon. Default: commander | commander |
| params | No | Command parameters (varies by command) | |
| command | Yes | Debug command to execute | |
| response_format | No | Output verbosity: concise=minimal output, detailed=full data | concise |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full weight and excels: it marks commands as 'Commander only,' discloses array truncation behavior for 'concise' responses, specifies required vs optional params per command, and ends with the exact return shape {success,data,error}. It even notes 'kill_app' supports force and timeout.
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 long, but due to 29 subcommands it is appropriately sized. It is well-structured with headers (QUICK REFERENCE, RESPONSE FORMAT, command categories, EXAMPLES) that front-load critical info and allow quick navigation. Every section serves a purpose and examples clarify usage.
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?
The description covers app support, command categories, parameter details, output verbosity, filtering best practices, and the final response envelope. Since there is no output schema, stating 'Returns { success: boolean, data?: unknown, error?: string }' is essential and done well. It also includes a practical EXAMPLES section.
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?
Although the schema fully documents top-level parameters, the generic 'params' object is opaque. The description compensates by detailing the required and optional parameters for every command (e.g., task_id, status, uid, value, key, direction) and providing real examples. This goes far beyond the schema's generic 'varies by command'.
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 opens with 'Debug and inspect Tauri applications via WebSocket,' providing a specific verb and resource. It then enumerates 29 subcommands organized by category, making the tool's scope unmistakable despite no sibling tools.
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?
It explains multi-app support with the 'app' parameter and default 'commander,' provides example invocations, and includes a 'FILTERING TASKS (avoid loading all tasks)' section with concrete parameter usage. It also documents the 'response_format' option and when to use 'concise' vs 'detailed'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
There is only one tool, so there is no possibility of confusing it with another tool. The tool name clearly indicates its purpose, and the internal commands are well-documented.
With a single tool, naming consistency is inherently satisfied. The name 'tauri_debug_command' is descriptive and follows a clear, consistent pattern.
The server exposes only one tool despite covering a broad range of functionality (app lifecycle, tasks, system metrics, UI automation). This is a significant mismatch—the scope warrants multiple focused tools rather than a single oversized one.
The tool bundles a comprehensive set of commands covering app lifecycle, health checks, system metrics, task management (Commander-specific), sessions, UI automation, and more. It covers the main debugging workflows for Tauri apps, though some task mutation operations are absent, leaving minor gaps.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
A Model Context Protocol (MCP) server for Selise Blocks Cloud integration
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
MCP server to assist with JxBrowser development.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Related MCP Servers
- AlicenseBqualityBmaintenanceA Model Context Protocol server that provides comprehensive Electron application automation, debugging, and observability capabilities through Chrome DevTools Protocol integration.425371MIT
- AlicenseBqualityBmaintenanceEnables AI assistants to automate and test Tauri desktop applications through the Model Context Protocol. It provides tools for app management, UI interaction, and state inspection across multiple platforms without requiring CDP dependencies.148971MIT
- AlicenseAqualityAmaintenancechrome-debug-mcp is an asynchronous Rust-based Model Context Protocol (MCP) server that allows AI agents and Large Language Models to natively debug Chromium-based browsers via the Chrome DevTools Protocol (CDP).2354MIT
- AlicenseNot gradedqualityBmaintenanceAn MCP server that allows AI agents to interact with and debug Tauri applications through screenshots, DOM access, input simulation, and more.897108MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/ruizrica/rust-debug-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server