Skip to main content
Glama
ruizrica

rust-debug-mcp

by ruizrica

rust-debug-mcp

TypeScript Rust Tauri WebSocket Model Context Protocol

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 (concise and detailed)

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 build

Installing 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 start

The 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

tauri_debug_command

Execute a debug command against a selected app (command, optional params, optional app, optional response_format)

Command Categories

  • App lifecycle: start_app, kill_app

  • Core: test_connection, get_debug_mode, set_debug_mode, get_app_dir, get_logs, get_system_metrics, test_command, simple_test

  • Task/session/metrics: get_session_metrics, get_task_metrics, get_all_tasks, get_task, get_tasks_by_status, get_task_groups, list_windows

  • Frontend action: broadcast_to_frontend

  • UI 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.json

Build

npm run build

Typecheck

npm run typecheck

Testing

npm test
npm run test:unit
npm run test:integration

Contributing

Contributions are welcome.

  1. Fork the repository

  2. Create a feature branch

  3. Make and test your changes

  4. Open a pull request

License

MIT


Built with TypeScript, Rust, Tauri, and MCP.

Available Tools

1 tool
tauri_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 }

ParametersJSON Schema
NameRequiredDescriptionDefault
appNoTarget app to debug. Available: commander, photon. Default: commandercommander
paramsNoCommand parameters (varies by command)
commandYesDebug command to execute
response_formatNoOutput verbosity: concise=minimal output, detailed=full dataconcise

TDQS

A5/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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

A4.7/5.0
Disambiguation5/5

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.

Naming Consistency5/5

With a single tool, naming consistency is inherently satisfied. The name 'tauri_debug_command' is descriptive and follows a clear, consistent pattern.

Tool Count2/5

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.

Completeness4/5

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

ActivityInactive
ResponsivenessSyncing

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

Related MCP Servers

Latest Blog Posts

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