httptoolkit-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HTK_SERVER_URL | No | HTTP Toolkit server URL | http://127.0.0.1:45457 |
| HTK_SERVER_TOKEN | No | Authentication token (if server requires one) |
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 |
|---|---|
| get_versionA | Get the current HTTP Toolkit server version |
| get_configB | Get HTTP Toolkit proxy configuration including certificate paths, network interfaces, system proxy, and DNS servers |
| get_network_interfacesB | List all network interfaces on the system |
| trigger_updateB | Trigger an update check for the HTTP Toolkit server |
| shutdown_serverA | Shutdown the HTTP Toolkit server. WARNING: This will stop all interception. |
| list_interceptorsA | List all available HTTP traffic interceptors (browsers, terminals, mobile devices, Docker, etc.) and their activation status |
| get_interceptor_metadataC | Get detailed metadata for a specific interceptor. Returns available targets like Docker containers, Android devices, JVM processes, etc. |
| deactivate_interceptorB | Deactivate a running interceptor and stop capturing its traffic |
| intercept_chromeA | Launch a fresh independent Chrome window with all HTTP(S) traffic intercepted. The browser uses an isolated profile so it won't affect your normal browsing. |
| intercept_firefoxA | Launch a fresh independent Firefox window with all HTTP(S) traffic intercepted. Uses an isolated profile. |
| intercept_fresh_terminalA | Open a new terminal window where all launched processes and Docker containers will have their HTTP(S) traffic intercepted automatically. |
| intercept_existing_terminalA | Get a command to run in an existing terminal to start intercepting HTTP(S) traffic from processes launched in that terminal. Returns shell-specific commands for bash, zsh, fish, etc. |
| intercept_docker_containerB | Intercept all HTTP(S) traffic from a running Docker container. Injects proxy settings into the container to capture all outgoing HTTP traffic. |
| intercept_android_adbA | Intercept HTTP(S) traffic from an Android device or emulator connected via ADB. Automatically injects system HTTPS certificates into rooted devices and most emulators. |
| frida_android_setupA | Set up a Frida host on an Android device connected via ADB. This prepares the device for app-level interception by installing the Frida server and CA certificate. |
| frida_android_launchB | Launch the Frida server on an Android device. Must run frida_android_setup first. |
| frida_android_interceptA | Intercept a specific Android app using Frida dynamic instrumentation. Automatically disables most certificate pinning. Requires a rooted device with Frida server running (use frida_android_setup and frida_android_launch first). |
| frida_ios_interceptA | Intercept a specific iOS app using Frida dynamic instrumentation. Automatically disables most certificate pinning. Requires a jailbroken device running Frida Server connected via USB. |
| intercept_jvmA | Attach to a running JVM process (Java, Kotlin, Clojure, etc.) to intercept all its HTTP(S) traffic. Uses Java agent attachment. |
| intercept_electronB | Launch an Electron application with all its HTTP(S) traffic intercepted. Use get_interceptor_metadata with id "electron" to list available Electron apps. |
| send_http_requestA | Send an HTTP request through the HTTP Toolkit proxy. The request will be intercepted and visible in the HTTP Toolkit UI. Returns the full response including status code, headers, and body. |
| activate_interceptorA | Generic tool to activate any interceptor by ID with custom options. Use the dedicated tools (intercept_chrome, intercept_docker_container, etc.) when possible for better parameter validation. |
| capture_trafficA | Capture live HTTP(S) traffic being intercepted by HTTP Toolkit. Creates a temporary session, subscribes to traffic events via WebSocket, collects requests and responses for the specified duration, then returns all captured exchanges. Use this to see what HTTP requests are being made by intercepted browsers, apps, or containers. |
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 23 tools
Most tools have distinct purposes, such as intercepting different targets (Chrome, Docker, Android) or managing interceptors. However, some overlap exists: 'activate_interceptor' is a generic version that could be confused with specific intercept tools like 'intercept_chrome', though descriptions clarify this. The dedicated tools are well-differentiated by target type.
Tool names follow a highly consistent verb_noun pattern throughout, such as 'activate_interceptor', 'capture_traffic', 'deactivate_interceptor', and 'list_interceptors'. All tools use snake_case uniformly, with clear verbs like 'intercept', 'get', 'list', and 'send', making the naming predictable and easy to understand.
With 23 tools, the count is slightly high but reasonable for the comprehensive scope of HTTP traffic interception across multiple platforms (browsers, mobile, Docker, terminals). Each tool serves a specific function, such as setup, activation, or management, though some consolidation might be possible without losing functionality.
The tool set provides complete coverage for HTTP Toolkit's domain, including interceptor activation/deactivation, traffic capture, platform-specific setup (Android, iOS, JVM), configuration retrieval, and server management. There are no obvious gaps; tools support the full lifecycle from setup to shutdown, ensuring agents can handle all core workflows without dead ends.