dejank
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DEJANK_METRO_HOST | No | Where Metro runs | localhost |
| DEJANK_METRO_PORT | No | Metro port | 8081 |
| DEJANK_ARTIFACT_DIR | No | Where profiles and screenshots are saved | .dejank/artifacts |
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 | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| investigate_slow_screenA | PREFERRED one-shot: profile JS + React around an optional tap, fetch component names, return rule-based diagnosis + artifact paths. Use this instead of chaining start/stop/tap tools when asking why a screen is slow. |
| list_targetsC | List Metro/CDP debug targets for the connected React Native app |
| get_target_infoB | Get details for one Metro CDP target by id |
| get_capabilitiesC | Live capability probes (CDP, profilers, UI). May take 30–60s. |
| get_ui_treeC | Compact UI tree (Android uiautomator / iOS AX) |
| tapB | Tap by label (e.g. "Go to next screen") or x/y |
| get_device_logsD | Native logs — Android logcat / iOS Simulator unified logs |
| capture_js_profileA | Capture Hermes JS CPU profile for durationMs; writes artifact under .dejank/artifacts |
| start_js_profileB | Start Hermes JS CPU profiler (pair with stop_js_profile around a repro) |
| stop_js_profileA | Stop JS CPU profiler and save artifact |
| capture_react_profileC | Capture React Profiler session via Fusebox CDP; writes artifact |
| start_react_profileC | Start React Profiler (Fusebox); pair with stop_react_profile |
| stop_react_profileA | Stop React Profiler and save profilingData artifact |
| get_component_treeC | Best-effort React component display names / renderer info via Fusebox DevTools operations |
| take_screenshotA | Capture device screenshot (adb / simctl) to .dejank/artifacts |
| list_artifactsC | List recent TracePilot evidence artifacts |
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 16 tools
Each tool has a clearly distinct purpose: target discovery, capability probing, JS/React profiling (start/stop/capture), UI tree, interaction, logs, screenshots, and artifact listing. The profile tools are differentiated by 'js' vs 'react' and 'start/stop/capture', and the high-level investigate_slow_screen is explicitly preferred over chaining, reducing ambiguity.
All tools use snake_case with a verb-first pattern (investigate_, list_, get_, start_, stop_, capture_, take_, tap). The modifiers 'js' vs 'react' and 'profile' are applied uniformly, creating a predictable and readable convention.
16 tools is slightly above the typical 3-15 well-scoped range, but each tool serves a distinct purpose in the performance diagnostic workflow. The redundancy between capture and start/stop pairs is justified by different use cases (fixed-duration vs manual repro), so the count is reasonable if slightly heavy.
The tool set covers the full diagnostic lifecycle: target discovery, capability probing, JS and React profiling, UI tree inspection, interaction, device logs, screenshots, and artifact management. The one-shot investigate_slow_screen provides a high-level entry point, while the granular tools allow manual control, leaving no obvious gaps for the stated purpose.