mitmweb-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 |
|---|---|
| statusA | Check connectivity to mitmweb and report how many flows are captured. Start here when something is not working. |
| flow_statsA | Overview of captured traffic: hosts, status codes, asset ratio, hottest endpoints. This is the first thing to run against an unfamiliar site: it tells you which host the interesting API lives on and whether anything is failing. Numeric path segments are normalised to {n}, so /user/1001 and /user/1002 are counted as one endpoint. |
| list_flowsA | List recent flows, newest first. Static assets (js/css/images/fonts) are excluded by default — the equivalent of
mitmproxy's Two parameters make the human's UI actions usable as input:
url_contains matches the full URL including host and query string; content_type is a substring match against the response type, e.g. "json". |
| inspect_flowA | Full detail for one flow: URL, query params, both header sets, both bodies, latency, and a ready-to-run equivalent curl command. |
| get_contentA | Fetch one full body (gzip/brotli already decoded). which = request | response. Use this instead of inspect_flow when the body is large and you need more than inspect_flow's 4000-character preview. |
| search_flowsA | Full-text search across flows: "which request carried or returned this value?" This is the usual entry point for reverse-engineering an API. Take a distinctive value visible in the page (an order number, a username, a token) and search for it to find the endpoint that produced it. scope = all | url | headers | body. With regex=True the keyword is a regular expression, e.g. "sign=[a-f0-9]{32}". Scans backwards from the newest flow, at most max_scan flows. |
| diff_flowsA | Compare two requests field by field — the tool for reverse-engineering signatures. Typical use: call the same endpoint twice (or capture it before and after paging), then diff. Parameters that stay the same are omitted from the output, so what remains is exactly the set that varies per request: nonce, timestamp, signature. That tells you which fields any signing algorithm must reproduce. JSON bodies are flattened to a.b.c keys and compared per key. Non-JSON bodies are returned verbatim for both sides so you can judge them yourself. |
| detect_authA | Scan all traffic and report which authentication schemes the site uses. Run this when picking up an unfamiliar target: it answers "what exactly do I have to forge in order to call this API without a browser?" — a bearer token, a session cookie, a custom API-key header, or a signed request. Each finding includes sample flow ids you can pass straight to inspect_flow. |
| generate_codeA | Turn captured flows into a runnable scraper script — the final deliverable. flow_ids may be a list or a comma-separated string. The order is preserved in the generated script and all requests share one Session, so a "log in, then call the API" sequence replays correctly with cookies carried across. framework = curl_cffi (default; TLS fingerprint impersonation, best for scraping) | httpx | requests | curl (emits a shell script instead). Original request headers are kept, minus the ones the client manages itself. |
| replay_flowA | Replay a request, optionally rewriting method, headers or body (like Burp Repeater). The request is sent with curl_cffi using browser TLS fingerprint impersonation, and it goes through your own mitmproxy, so the result appears as a new flow in your mitmweb UI where you can see it. Existing flows are never modified. headers overrides or adds headers, e.g. {"Authorization": "Bearer NEW"}; omit to reuse the original. body replaces the request body (dicts/lists are serialised to JSON). impersonate accepts chrome / chrome131 / chrome142 / safari / firefox / edge. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |