Skip to main content
Glama
ruizrica

rust-debug-mcp

by ruizrica

tauri_debug_command

Execute debug commands on Tauri apps over WebSocket: manage app lifecycle, inspect tasks, run UI automation, and retrieve logs/metrics.

Instructions

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 }

Input Schema

TableJSON 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
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.

Install Server

Other Tools

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