Debug MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LOG_FILE | No | Log file path (relative to project directory) | .debug/debug.log |
| DEBUG_HOST | No | HTTP Server Host. Use 'localhost' for local connections only (default), '0.0.0.0' to accept connections from any device on your network, or your LAN IP (e.g., '192.168.1.100') to allow other devices to send logs | localhost |
| DEBUG_PORT | No | HTTP Server Port (optional, auto-assigned by default). If set, this port will be used; if not set, system automatically assigns an available port |
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 |
|---|---|
| get_server_infoA | Get debug MCP server configuration, HTTP endpoints, and supported environments. Use this first to verify the server is running correctly. |
| get_server_portA | Get the current HTTP server port and URL information. The port is dynamically assigned by the system to avoid conflicts. Use this to get the actual port number and endpoints for sending debug logs. |
| analyze_bugA | Analyze a bug description and provide intelligent suggestions about possible causes, affected files, and debugging strategies. This helps you understand what might be causing the issue before adding debug logs. |
| detect_environmentA | Automatically detect the runtime environment (browser, node, python, php, react-native, wechat) of a specific file. Use this to determine which debug code template to use. |
| get_debug_templateA | Get a debug code template for a specific environment. ⚠️ IMPORTANT INSTRUCTIONS FOR AI: 1) DO NOT use console.log() - the generated code uses HTTP POST to send logs to the debug server, 2) ALWAYS provide the projectPath parameter as the absolute path to the project directory (e.g., /path/to/project or process.cwd()), 3) The debug logs will be stored at {projectPath}/.debug/debug.log in the project directory, NOT in the user home directory. After getting the template, manually insert it into the appropriate location in the user's file. ⚠️ AFTER INSERTING DEBUG CODE: You MUST inform the user about: 1) What you suspect might be wrong, 2) What specific test steps they should take, 3) What results to expect, 4) How to report back the results. After user tests, use read_debug_logs to analyze the actual runtime data. ⚠️ MARKING TEMPORARY MODIFICATIONS: ANY temporary changes for debugging (including visual markers, test images, placeholder text, button label changes, color highlights, etc.) MUST be wrapped with clear comments: "// TEMPORARY DEBUG MARKER - WILL BE REVERTED" at the start and "// END TEMPORARY DEBUG MARKER" at the end. Keep a list of ALL temporary modifications (both debug code AND visual/test changes) and ensure ALL are reverted during cleanup. |
| read_debug_logsA | Read debug logs from the project. Logs are stored in {projectPath}/.debug/debug.log. Use this to analyze what happened during runtime execution after the user has tested the code with injected debug logs. ⚠️ IMPORTANT: If the user confirms the bug is FIXED (e.g., says "It works!", "Fixed!", "Success!", "Thanks!"), you should immediately: 1) Use clear_debug_logs to clear the log file, 2) Remove ALL debug code blocks (search for DEBUG CODE START/END markers), 3) Revert ALL temporary visual/test markers (search for "TEMPORARY DEBUG MARKER" comments), 4) Restore original code (button labels, images, styles, colors, etc.), 5) Confirm cleanup is complete. Do NOT ask for confirmation - just clean up directly when user confirms success. |
| list_debug_blocksA | List all debug blocks (code between debug-start and debug-end markers) in project files. Use this to see what debug code has been injected. |
| clear_debug_logsA | Clear all debug logs from the project log file. Use this before starting a new debugging session to avoid confusion from old logs. |
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 8 tools
Each tool has a clearly distinct purpose with no overlap: analyze_bug for bug analysis, clear_debug_logs for log cleanup, detect_environment for environment detection, get_debug_template for code templates, get_server_info for server configuration, get_server_port for port details, list_debug_blocks for listing debug code, and read_debug_logs for log analysis. The descriptions reinforce unique functions, preventing misselection.
All tools follow a consistent verb_noun naming pattern (e.g., analyze_bug, clear_debug_logs, detect_environment), using snake_case throughout. This predictability makes the tool set easy to navigate and understand, with no deviations in style or convention.
With 8 tools, the server is well-scoped for debugging support, covering essential aspects like analysis, environment detection, template generation, log management, and server configuration. Each tool serves a specific role, avoiding bloat while providing comprehensive coverage for the domain.
The tool set offers complete coverage for a debugging workflow: from initial bug analysis and environment detection to injecting debug code, managing logs, and cleaning up. It includes both proactive (e.g., get_debug_template) and reactive (e.g., read_debug_logs) tools, with no obvious gaps that would hinder an agent's ability to debug effectively.