Switch 2 Emulator Diagnostics MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| emulator_get_statusB | Get current emulator runtime status, active title, uptime, CPU/RAM, and Vulkan GPU backend. |
| emulator_get_performanceB | Measure real-time FPS, frametimes (ms), and CPU utilization. |
| emulator_get_shader_statsC | Inspect Shader Cache v2 (lichii-cache.v2.bin) records, compute/graphics pipelines, and legacy migration. |
| emulator_get_rendering_defectsC | Inspect skipped draws (zero-stutter indicator) and Vulkan validation or compilation errors. |
| emulator_get_live_logsB | Filter and extract emulator logs by subsystem (e.g. Render.Vulkan, Core.ARM) and severity. |
| emulator_diagnose_gameC | Perform comprehensive automated diagnosis of bottlenecks (CPU bound, GPU compute, Shader stall). |
| emulator_capture_screenshotB | Capture screenshot of the emulator viewport for multimodal AI visual inspection. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Each tool targets a fairly distinct data source: runtime status, performance metrics, shader cache records, rendering defects, logs, and screenshots. There is mild overlap between emulator_get_status (CPU/RAM, GPU backend) and emulator_get_performance (FPS, CPU utilization), and emulator_diagnose_game aggregates the same signals, but an agent can still pick correctly from the descriptions.
All tools share the emulator_ prefix and a predictable verb_noun structure (get_status, get_performance, get_shader_stats, diagnose_game, capture_screenshot). The single non-get verb pair (diagnose/capture) maps cleanly to actions that are genuinely not simple reads.
Seven tools is well within the ideal 3-15 range and each covers a distinct diagnostic surface (status, perf, shaders, defects, logs, aggregate diagnosis, visual capture). No tool feels redundant padding given the stated read-only diagnostic purpose.
The read-only diagnostic lifecycle is covered end to end: raw metrics, cache inspection, defect detection, logs, and an aggregated diagnosis plus visual evidence. Gaps exist for remediation or export actions (clear/rebuild shader cache, change GPU backend or log level, export a diagnostic bundle), which agents may want after diagnosing a bottleneck.