mitmproxy-mcp

Overview Schema Source Related Servers Discussions Admin

start_proxy

Start a custom HTTP/HTTPS proxy for traffic interception and analysis. Set port, save traffic to a dump file, or route via an upstream proxy.

Instructions

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').

Input Schema

TableJSON Schema

Name	Required	Description	Default
`port`	No
`dump_file`	No
`upstream_proxy`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.7.0Sep 23, 2026

addedInput schema / properties / dump_file

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Dump File"
+}

addedInput schema / properties / port / anyOf

Added value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / port / default
```
Previous value: -8080New value: +null
```
removedInput schema / properties / port / type
```
Removed value: -"integer"
```

addedInput schema / properties / upstream_proxy

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Upstream Proxy"
+}

First observedv0.6.0May 29, 2026

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of disclosing behavior. It reveals useful details like default port precedence and dump_file append semantics, but it does not say whether starting is idempotent, long-running, or repeatable, nor what happens to an already-running instance. The basic 'start' side effect is stated, but lifecycle behavior is missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded: one clear purpose sentence followed by brief argument bullets. Every sentence earns its place, and the structure makes the information highly scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

All parameters are documented and the output schema exists, so invocation details are mostly covered. However, the lack of annotations and the absence of lifecycle/usage context, such as how to stop the proxy or what happens on repeated starts, leave a meaningful gap for an agent deciding how to manage the proxy instance.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate, and it does thoroughly. It explains port default resolution, dump_file optional use with the '+' append prefix, and upstream_proxy with an example URL. Every parameter receives meaningful semantic detail beyond the nullable/default schema entries.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states exactly what the tool does: 'Start the mitmproxy instance.' This uses a specific verb and resource and clearly differentiates it from siblings like stop_proxy and traffic-analysis tools. It is not a tautology and leaves no ambiguity about the tool's core function.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance about when to use start_proxy versus alternatives, when not to use it, or what prerequisites exist. The parameter notes explain defaults but do not address usage context, such as needing to start the proxy before capture tools or pairing it with stop_proxy.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.