mitmproxy-mcp
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 | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| start_proxyA | Start the mitmproxy instance. Args: port: Port to listen on. Omit to use the server's configured default (--port / MITMPROXY_PORT, else 8080). dump_file: Optional file path to save raw mitmproxy .flow data. Prefix with + to append to an existing file. upstream_proxy: Optional upstream proxy URL (e.g., 'http://user:pass@proxy:port'). |
| stop_proxyD | – |
| set_scopeD | – |
| set_global_headerD | – |
| remove_global_headerD | – |
| get_traffic_summaryD | – |
| inspect_flowA | Get full details of a captured flow. Args: flow_id: The ID of the captured flow full_body: If True, return full request body instead of 2000-char preview |
| inspect_flowsA | Batch inspect multiple flows in one call. Reduces context usage vs calling inspect_flow N times. Args: flow_ids: Comma-separated list of flow IDs to inspect fields: Comma-separated list of DB columns to select. e.g. "id,url,method,request_headers,request_body" to skip response data. Default: all columns. full_body: If True, return full request body instead of preview |
| get_flow_schemaC | Infer a simple schema from a flow's JSON response body. |
| load_traffic_fileA | Import flows from a HAR or mitmproxy flow file into the traffic database. After import, all traffic inspection tools work on the imported data. No proxy needs to be running. Args: file_path: Path to .har or .mitm/.flow file append: If True, keep existing traffic. If False (default), clear first. scope: Comma-separated list of domains to filter by during import. Only flows matching these domains are imported. |
| extract_from_flowB | Extract specific data from a flow's response body using JSONPath or CSS selectors. Args: flow_id: The ID of the captured flow json_path: A JSONPath expression to extract data from a JSON response css_selector: A CSS selector to extract data from an HTML/XML response |
| search_trafficC | Search captured traffic using filters. Args: query: Keywords to search in URL or body domain: Filter by domain name method: Filter by HTTP method (GET, POST, etc.) limit: Max results to return |
| set_session_variableC | Manually set a session variable to use in replayed flows. |
| extract_session_variableA | Extract a value from a flow's response body using a regex and store it as a session variable. Args: name: Variable name (referenced as $name in replay_flow) flow_id: The ID of the flow to extract from regex_pattern: The regex pattern with capture groups group_index: Which regex capture group to extract (default: 1) |
| clear_trafficA | Clear all captured traffic from the database. |
| fuzz_endpointA | Fuzz an endpoint by substituting a target parameter with a category of DAST payloads. Args: flow_id: The flow to replay as the base request. target_param: The name of the parameter to replace. param_type: The location of the parameter: 'query' or 'json_body'. payload_category: The category of payloads ('sqli', 'xss', 'path_traversal'). |
| replay_flowC | Replay a captured flow, optionally with modified method, headers, or body. Supports session variable injection (e.g., $token) in headers and body. |
| add_interception_ruleD | – |
| list_rulesD | – |
| clear_rulesD | – |
| list_toolsA | List all available tools with their descriptions. |
| export_openapi_specA | Exports captured API traffic patterns to an OpenAPI v3 JSON specification. Args: domain: Filter traffic by domain limit: Max number of traffic flows to analyze. None = all flows. |
| get_api_patternsB | Cluster captured traffic into endpoint patterns. Args: domain: Filter traffic by domain limit: Max number of flows to analyze. None = all flows. |
| detect_auth_patternD | – |
| generate_scraper_codeB | Generate executable scraper/automation code from a comma-separated list of flow IDs. Args: flow_ids: Comma-separated list of flow IDs to include in the script. target_framework: The framework to generate code for. |
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 25 tools
Most tools target a distinct action or resource: proxy lifecycle, traffic inspection, extraction, replay, rules, and export are clearly separated. The main ambiguities are the blank descriptions for several tools (get_traffic_summary, set_scope, detect_auth_pattern, etc.) and the close relationship between extract_from_flow and extract_session_variable, though their purposes are still distinct.
Every tool follows a consistent snake_case verb_noun convention: start_proxy/stop_proxy, inspect_flow/inspect_flows, set_scope, clear_traffic, replay_flow, fuzz_endpoint. Even compound operations like export_openapi_spec and generate_scraper_code fit the pattern cleanly. No naming convention mixing or vague single-word verbs exist.
At 25 tools, this sits right at the upper boundary of acceptable size for a proxy/HTTP traffic analysis server. The breadth is mostly justified by the many sub-domains (capture, inspection, extraction, replay, rules, export), but several tools have minimal descriptions and could potentially be consolidated. It is not egregiously over-scoped, but it feels heavy.
The tool surface covers the full proxy workflow: start/stop, traffic capture, import, search, inspection, schema inference, extraction, session variables, replay, fuzzing, code generation, and OpenAPI export. Minor gaps exist such as no per-flow deletion, no rule editing beyond add/list/clear, and no obvious way to export raw traffic back out, but agents can work around these.