This MCP server (mitmproxy-mcp) enables LLMs to capture, inspect, replay, and modify HTTP/HTTPS/WebSocket traffic through mitmproxy. Key capabilities include:
Proxy Control: Start/stop the proxy with configurable options (SOCKS5, WireGuard VPN mode), and check status.
Flow Management: List, get, create, update, delete, and clear HTTP flows; save to or load from .mitm files for offline analysis.
Traffic Replay: Replay captured flows or send new custom HTTP requests.
Traffic Manipulation: Modify request/response bodies, headers, methods, status codes, and metadata (tags, marks, comments).
WebSocket Support: List flows, inspect sessions, inject messages into active connections, and set modification rules.
Automated Rules Engine: Define rules to automatically modify, drop, intercept, delay, or mark live HTTP/WebSocket traffic.
Mocking & URL Mapping: Create a mock server from recorded flows, map URLs to local files, or rewrite URLs to remote destinations.
HAR Interoperability: Import and export traffic in HAR format.
Certificate & mTLS Management: Export CA certificates, configure upstream verification, and set client certificates for mTLS.
Custom Cryptography: Load Python scripts to transparently decrypt/encrypt application-level traffic.
JSONPath Extraction: Extract specific JSON values from request or response bodies.
Capture Filters: Define include/exclude patterns to control which flows are captured.
MCP Resources: Read proxy status, recent flows, configuration, active rules, and events via resource URIs.
Documentation: Use tool_info to get detailed parameter explanations for any tool.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mitmproxy-mcp Start the proxy on port 8080 and list captured flows"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
一个基于 mitmproxy 构建的轻量级 Model Context Protocol (MCP) 服务器。它让 LLM 可以通过一小套工具来捕获、检查、重放和修改 HTTP 流量。
两种捕获模式
通过 proxy_ctl(cmd="start") 启动实时代理，实时捕获流量。
通过 http_ctl(cmd="load") 加载之前保存的 .mitm 文件进行离线分析。
核心操作
查看: http_ctl(cmd="list"), http_ctl(cmd="get")
重放: flow_action(action="replay"), flow_action(action="send") —— 基于 mitmproxy 原生 replay.client
修改: flow_action(action="update"), flow_action(action="create")
辅助代理（可选） 支持同时运行第二个 mitmproxy 实例，用于链式代理场景下的加解密分工。
基于 mitmproxy 自身引擎 实现重放和保存，不重复造轮子。
stdio 传输，开箱兼容 Claude Desktop。
SSE 传输，可远程或网络客户端连接（Claude Code、Cursor 等）。
如需可视化界面，可直接使用 mitmproxy 自带的 Web UI（mitmweb）。
Related MCP server: httptoolkit-mcp
需要 Python 3.13+ 和 uv。
uv venv
uv pip install -e .复制以下内容发送给任意 Agent，让它根据提示完成安装：
安装 mitmproxy-mcp MCP 服务和配套 skill。请阅读 https://raw.githubusercontent.com/u33pk/mitmproxy-mcp/refs/heads/main/INSTALL.md 中的内容，根据提示安装 mcp 和配套 skill。将以下内容添加到你的 Claude Desktop 配置中（macOS: ~/Library/Application Support/Claude/claude_desktop_config.json，Windows/Linux 路径可能不同）：
{
"mcpServers": {
"mitmproxy": {
"command": "uv",
"args": [
"--directory",
"/path/to/mitmproxy-mcp",
"run",
"mitmproxy-mcp"
]
}
}
}示例配置也可参考 examples/mcp-config.json。
启动 SSE 服务器：
uv run mitmproxy-mcp --transport sse --host 127.0.0.1 --port 8081然后在 MCP 客户端配置中连接：
{
"mcpServers": {
"mitmproxy": {
"type": "sse",
"url": "http://127.0.0.1:8081/sse"
}
}
}将浏览器或客户端配置为使用 proxy_ctl(cmd="status") 显示的代理地址（默认 127.0.0.1:8080）。
让 LLM 执行 proxy_ctl(cmd="start")。
浏览网页或调用 API。
让 LLM 执行 http_ctl(cmd="list") 和 http_ctl(cmd="get") 检查流量。
使用 flow_action(action="replay") 重发请求，或用 flow_action(action="update") + flow_action(action="replay") 修改后重发。
proxy_ctl(cmd="start") 接受 extra_options 字典，直接透传给 mitmproxy 的 options.Options。这样 LLM 可以启用 SOCKS5、原始 TCP/UDP 捕获、主机过滤等。
{
"host": "127.0.0.1",
"port": 8080,
"extra_options": {
"mode": ["socks5"],
"tcp_hosts": ["example.com"],
"udp_hosts": ["dns.example.com"]
}
}使用 proxy_ctl(cmd="list_options") 查看所有可用键及其默认值。
检查大体积响应体时，使用 http_ctl(cmd="get") 的 max_content_size 避免占满 LLM 上下文：
{
"cmd": "get",
"flow_id": 1,
"max_content_size": 4096
}JSON 体会返回紧凑的 结构预览。
非 JSON 文本体会 截断 并附加提示。
要从 JSON 请求或响应体中提取特定值，使用 http_ctl(cmd="extract_json") 配合 JSONPath 表达式：
{
"cmd": "extract_json",
"flow_id": 1,
"target": "response",
"jsonpath": ["$.data.users[*].name", "$.meta.total"]
}支持与 Chrome DevTools、Charles、ProxyMan 等工具互操作：
# 导出全部捕获流量为 HAR
http_ctl(cmd="export_har", path="/tmp/capture.har")
# 只导出指定 flow
http_ctl(cmd="export_har", path="/tmp/capture.har", flow_ids=[1, 2, 3])
# 从 HAR 文件导入流量到 store
http_ctl(cmd="import_har", path="/tmp/capture.har")二进制内容会自动 base64 编码；导入失败的单条 entry 会被跳过并记录日志，不影响其余 entry。
拦截 HTTPS 需要信任 mitmproxy 的 CA 证书：
# 证书位置
~/.mitmproxy/mitmproxy-ca-cert.cer将其安装到浏览器或系统钥匙串。详见 mitmproxy 文档。
ca_ctl)ca_ctl 专门管理证书与 CA 设置，独立于 proxy_ctl：
命令 | 作用 |
| 查看当前 CA/证书配置 |
| 导出 mitmproxy CA 证书到指定目录 |
| 启用/禁用上游服务器证书校验 |
| 设置校验上游用的 CA 文件或目录 |
| 清空上游 CA 设置 |
| 设置 mTLS 客户端证书（可选 key/passphrase） |
| 清空客户端证书 |
示例：
# 导出 CA 给客户端安装
ca_ctl(cmd="export_ca", output_dir="/tmp")
# 双向校验：用指定 CA 验证上游服务器
ca_ctl(cmd="set_verify_upstream", enabled=True)
ca_ctl(cmd="set_upstream_ca", ca_path="/path/to/server-ca.pem")
# mTLS
ca_ctl(cmd="set_client_cert", cert_path="/path/to/client.pem", key_path="/path/to/client.key")证书配置会持久保存在 ProxyManager 中，代理停止/重启后仍然有效；代理运行期间设置会立即通过 mitmproxy set 命令生效。
每条流现在都会暴露协议层元数据，便于区分 HTTP/1.1、HTTP/2 和 HTTP/3（QUIC）流量：
{
"protocol": {
"request_http_version": "HTTP/2",
"response_http_version": "HTTP/2",
"client_alpn": "h2",
"server_alpn": "h2",
"client_tls_version": "TLSv1.3",
"server_tls_version": "TLSv1.3",
"client_sni": "example.com",
"server_sni": "example.com"
}
}在 WireGuard 模式下，UDP/QUIC 流量会被路由到 mitmproxy，因此可以完整观察到 HTTP/3 连接及其 ALPN/TLS 信息。
除了常规 HTTP/SOCKS 代理，proxy_ctl(cmd="start") 还支持 WireGuard 模式。启动时会自动生成服务端与客户端密钥，并返回可直接导入 iOS、Android、macOS、Windows 的 WireGuard 客户端配置：
{
"cmd": "start",
"host": "0.0.0.0",
"port": 51820,
"extra_options": {
"mode": ["wireguard"]
}
}返回的 wireguard_config 字段即为客户端 INI 配置。之后可通过 proxy_ctl(cmd="wireguard_config") 再次获取。
注意：WireGuard 是 Layer-3 VPN，会捕获所有流量（包括 QUIC/HTTP3），但仍需信任 mitmproxy CA 证书才能解密 HTTPS/HTTP3 内容。
websocket_ctl）WebSocket 连接以 HTTP upgrade 流的形式被捕获，现在由独立的 websocket_ctl 工具管理：
# 列出 WebSocket 流
websocket_ctl(cmd="list")
# 查看完整会话
websocket_ctl(cmd="get", flow_id=1, max_content_size=4096)返回结构：
{
"is_websocket": true,
"websocket": {
"messages": [
{"from_client": true, "type": "text", "text": "hello"},
{"from_client": false, "type": "text", "text": "echo: hello"}
],
"close_code": 1000
}
}二进制消息会 base64 编码（content_encoding="base64"）。
向已建立的 WebSocket 连接主动发消息：
websocket_ctl(cmd="inject", flow_id=1, message="hello from mcp", to_client=False)to_client=True 发给客户端，to_client=False 发给服务端。
binary=True 时以二进制帧发送。
MCP 服务器自己作为客户端，经代理连接目标 WebSocket：
websocket_ctl(
cmd="connect",
url="ws://echo.example.com/",
messages=["hello"],
wait_for=1,
timeout=10,
)返回里会包含捕获到的 flow_id 和收到的消息列表。
对实时 WebSocket 消息设置修改/丢弃规则：
websocket_ctl(cmd="add_rule", rule={
"id": "drop-ping",
"flow_filter": "~d api.example.com",
"direction": "client",
"message_filter": "^ping$",
"action": "drop",
})
websocket_ctl(cmd="add_rule", rule={
"id": "replace-echo",
"direction": "server",
"message_filter": "echo:",
"action": "replace_regex",
"replacement_regex": "echo:",
"replacement": "modified:",
})支持的动作：drop、replace、replace_regex。
crypt_ctl）对于用户态加密的应用（前端/APP 自定义加密协议），可以编写 Python 脚本实现透明的加解密。加载后，http_ctl get 会直接展示解密后的明文；修改明文后重放，flow_action(replay) 会自动重新加密。
crypt_ctl(cmd="load", script_path="/path/to/my_crypto.py")
crypt_ctl(cmd="list")
crypt_ctl(cmd="status", script_id="my-handler")
crypt_ctl(cmd="unload", script_id="my-handler")脚本只需要继承 CryptoHandler：
from mitmproxy_mcp.crypto import CryptoHandler, CryptoResult
class MyHandler(CryptoHandler):
id = "my-handler"
filter = "~u api.example.com"
def decrypt_request(self, flow):
return CryptoResult(body=decrypt(flow.request.raw_content))
def encrypt_request(self, flow, plaintext):
return CryptoResult(body=encrypt(plaintext))
def decrypt_response(self, flow):
if flow.response is None:
return None
return CryptoResult(body=decrypt(flow.response.raw_content))完整示例见 examples/crypto_xor_example.py（简单 XOR）和 examples/crypto_dynamic_key_example.py（从登录响应动态获取密钥）。
⚠️ 安全提示：
crypt_ctl会执行用户指定的 Python 文件，请只加载可信脚本。
CryptoHandler 被注入 store（全部捕获流量）和 context（跨请求状态），因此可以：
从 /auth/login 响应提取密钥并缓存到 self.context。
在 decrypt_request 中查询历史 handshake 流量来推导会话密钥。
返回 CryptoResult(error="...") 在 crypt_ctl status 中向 LLM 报告原因。
支持同时运行第二个 mitmproxy 实例（辅助代理），适用于链式代理场景下的加解密分工。
客户端 → mitmA (端口 8080) → Burp/其他代理 → mitmB (端口 8082) → 服务器mitmA（主代理）：解密客户端请求，加密返回给客户端的响应
mitmB（辅助代理）：加密发往服务器的请求，解密服务器响应
两个代理共享同一个 FlowStore，捕获的流量统一在 http_ctl 中查看。
# 1. 启动主代理
proxy_ctl(cmd="start", port=8080)
# 2. 启动辅助代理（不同端口）
proxy_ctl(cmd="start", proxy_id="aux", port=8082)
# 3. 分别加载加解密脚本
crypt_ctl(cmd="load", script_path="/path/to/decrypt_a.py") # 主代理
crypt_ctl(cmd="load", proxy_id="aux", script_path="/path/to/encrypt_b.py") # 辅助代理
# 4. 查看状态（自动合并显示两个代理）
proxy_ctl(cmd="status")
# 5. 停止辅助代理
proxy_ctl(cmd="stop", proxy_id="aux")以下工具通过 proxy_id（"main" 或 "aux"，默认 "main"）路由到指定代理：
工具 | 路由行为 |
|
|
| 加解密脚本按 proxy_id 隔离，互不干扰 |
| 自动规则按 proxy_id 隔离 |
| 捕获规则按 proxy_id 隔离 |
|
|
以下工具不需要 proxy_id，始终操作共享数据：
工具 | 说明 |
| 操作共享 FlowStore，两个代理的流量统一查看 |
|
|
| 操作 FlowStore 数据，不涉及代理路由 |
| 始终在主代理上运行 |
| 始终在主代理上运行 |
除 tools 外，服务器还暴露一组只读的 MCP resources，客户端可以像读取文件一样直接获取状态，减少 tool 调用次数：
Resource URI | 内容 |
| 代理运行状态、监听地址、捕获数量、CA 摘要 |
| 最近 20 条 flow 摘要（无 body，低上下文占用） |
| 单条 flow 完整详情 |
| 当前所有规则与加解密脚本汇总 |
| 最近 10 条内部事件摘要（代理启停、flow 捕获、规则匹配、crypto 错误等） |
| 已加载加解密脚本列表及错误状态 |
| 完整 CA/证书配置（verify_upstream、上游 CA、客户端证书） |
用法示例（概念）：
读取 mitmproxy://proxy/status 查看代理是否已启动
读取 mitmproxy://flows/latest 快速浏览最近流量
读取 mitmproxy://flows/42 查看第 42 条流量的完整详情
读取 mitmproxy://config/rules 查看当前生效的所有规则
读取 mitmproxy://events/latest 查看最近代理事件
读取 mitmproxy://crypto/scripts 查看已加载的加密脚本状态
读取 mitmproxy://ca/status 查看 CA/证书配置当前版本只支持读取，暂不支持订阅推送。
工具 | 命令 / 说明 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 任何工具/命令的渐进式文档 |
使用 tool_info 获取详细的参数说明和示例，而不必让静态工具列表变得臃肿。例如：
{"tool_name": "proxy_ctl", "cmd": "start"}你可以定义自动匹配实时流量并执行操作的规则。适用于模拟响应、注入请求头、拦截广告或暂停请求以便后续检查。
{
"id": "mock-api",
"name": "Mock example API",
"enabled": true,
"phase": "request",
"filter": "~u api.example.com/users",
"actions": [
{"type": "set_status", "status_code": 200},
{"type": "set_header", "target": "response", "name": "Content-Type", "value": "application/json"},
{"type": "set_body", "target": "response", "content": "{\"users\":[]}"}
]
}使用 rule_ctl(cmd="add", rule=...) 安装规则，rule_ctl(cmd="list") 查看，rule_ctl(cmd="clear") 移除全部规则。
支持的操作包括：set_header, remove_header, set_body, replace_body, set_status, set_path, set_method, delay, kill, intercept, resume, mark, comment, tag。
filter 字段使用 mitmproxy 的 flowfilter 语法（~u, ~m, ~h, ~t, ~c 等）。使用 intercept 暂停匹配的流，然后由 LLM 调用 flow_action(action="resume", flow_id=...) 或 flow_action(action="kill", flow_id=...)。
捕获规则决定哪些实时流量会被保存到内存。支持 include 和 exclude 操作，且可在代理运行时动态修改而无需重启。
[
{"id": "api-only", "filter": "~u api.example.com", "action": "include"},
{"id": "skip-health", "filter": "~u api.example.com/health", "action": "exclude"},
{"id": "skip-images", "filter": "~t image/*", "action": "exclude"}
]逻辑：
exclude 规则优先检查；任意匹配则丢弃该流。
如果存在任意 include 规则，则流必须至少匹配其中一个才会被捕获。
基础的 capture_filter 选项仍会作为前置过滤。
使用 capture_rule_ctl(cmd="add", rule=...) 添加规则，capture_rule_ctl(cmd="list") 查看，capture_rule_ctl(cmd="clear") 移除全部。
将捕获到的流变成本地 Mock 服务器。启动后，匹配请求会直接返回录制响应，无需访问真实服务器。
# 1. 启动代理并捕获一些真实流量
# 2. 使用 mock_server_start 回放已捕获的流# LLM 的概念用法：
mock_server_ctl(cmd="start", flow_ids=[1, 2, 3])
# 现在匹配录制请求的访问会返回录制响应。
mock_server_ctl(cmd="status")
mock_server_ctl(cmd="stop")这与 flow_action(action="replay") 不同：
flow_action(action="replay") 会向真实服务器重新发送请求。
mock_server_ctl(cmd="start") 会拦截入站请求并返回录制响应。
将请求映射到本地文件，或在转发前重写 URL。
为匹配 URL 提供本地文件：
{
"id": "api-mock",
"filter": "~u example.com/api/data",
"url_regex": "https://example.com/api/data",
"local_path": "/path/to/mock.json"
}将匹配 URL 重写为另一个源站：
{
"id": "staging-redirect",
"filter": "~u example.com/api",
"url_regex": "https://example.com/api(.*)",
"replacement": "https://staging.example.com/api$1"
}使用 map_local_ctl(cmd="add", rule=...) / map_remote_ctl(cmd="add", rule=...) 添加规则，map_local_ctl(cmd="list") / map_remote_ctl(cmd="list") 查看，*_ctl(cmd="clear") 移除全部。
你可以将 Playwright 指向 mitmproxy-mcp 代理来捕获浏览器流量：
from playwright.sync_api import sync_playwright
with sync_playwright() as p:
browser = p.chromium.launch(
proxy={"server": "http://127.0.0.1:8080"},
args=["--ignore-certificate-errors"],
)
context = browser.new_context(ignore_https_errors=True)
page = context.new_page()
page.goto("https://example.com")然后让 LLM 执行 flows_list 并检查捕获的请求。
完整集成测试见 tests/test_playwright_capture.py。运行方式：
uv pip install -e ".[dev]"
playwright install chromium
python -m pytest tests/test_playwright_capture.py -m integration -v手动运行服务器进行测试：
uv run mitmproxy-mcp运行单元测试（排除网络/浏览器集成测试）：
uv run pytest tests/ -q运行集成测试：
# Playwright 浏览器捕获测试
uv run pytest tests/test_playwright_capture.py -m integration -v
# 所有 MCP 工具端到端测试
uv run pytest tests/test_all_tools.py -m integration -vMIT
Create a new request flow and store it (without sending).
| Name | Required | Description | Default |
|---|---|---|---|
| method | Yes | ||
| url | Yes | ||
| headers | No | ||
| body | No | ||
| body_encoding | No | text | |
| comment | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only mentions creation and storage without side effects, return value, or any behavioral constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but could be slightly expanded to include more context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and 6 parameters, the description lacks context about what a 'request flow' is, what the output represents, and how this interacts with the system.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage and the description provides no additional meaning for any of the 6 parameters, relying solely on their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'request flow', and adds 'store it (without sending)' which distinguishes it from related tools like request_send and flow_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for creating flows that are not sent immediately, but does not explicitly state when to use this tool vs. alternatives like flow_update or flows_save.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a flow from memory.
| Name | Required | Description | Default |
|---|---|---|---|
| flow_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It only states 'Delete a flow from memory,' omitting whether operation is destructive, irreversible, requires permissions, or affects other data. This is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no waste, but it lacks necessary details. It is front-loaded but incomplete, earning a mid-range score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool performs a deletion operation and has an output schema, the description should explain return values or side effects. It does not, leaving the agent underinformed compared to similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add meaning beyond the schema for the single parameter 'flow_id'. Schema coverage is 0%, yet the description offers no additional context like how to obtain the ID or format constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'a flow', and specifies a scope 'from memory'. This distinguishes it from siblings like flow_create or flows_clear, but could be more explicit about the scope's implications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like flows_clear or flow_update. There is no mention of prerequisites, consequences, or conditions that make this tool appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full details of a single flow.
| Name | Required | Description | Default |
|---|---|---|---|
| flow_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like side effects, permissions, or return format. It only says 'get the full details', which is minimal. The output schema exists but is not referenced in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence that is front-loaded and contains no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter and an output schema, so a simple description might suffice, but it lacks any context about error handling, prerequisites, or the response structure. It is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the required flow_id parameter. It adds no meaning beyond the schema's title 'Flow Id'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'full details of a single flow', which distinguishes it from siblings like flows_list (multiple) and flow_create (creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor any mention of prerequisites or when not to use it. The description is a single statement with no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replay a captured flow using mitmproxy's built-in replay.client.
| Name | Required | Description | Default |
|---|---|---|---|
| flow_id | Yes | ||
| use_modified | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose any behavioral traits such as side effects (does it modify state?), safety (idempotent?), or requirements. 'Replay' implies action but no details on what happens.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks essential details. It is not front-loaded with critical information; it is minimal but not optimally structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters and an output schema, the description is insufficient. It does not explain the replay process, preconditions (e.g., proxy status), or what the output contains. The output schema exists but description adds no value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameters are not described at all. Schema description coverage is 0%, and the tool description does not explain what 'flow_id' or 'use_modified' mean. The default for 'use_modified' is mentioned but not its effect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Replay a captured flow') and specifies the resource ('captured flow') and method ('using mitmproxy's built-in replay.client'). It distinguishes from sibling tools that create, delete, get, etc., by focusing on replaying.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus others. No mention of prerequisites or context (e.g., proxy must be running, flow must be captured). The description is purely functional without any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear all in-memory flows. Optionally stop the proxy too.
| Name | Required | Description | Default |
|---|---|---|---|
| stop_proxy | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations exist, the description carries full burden. It discloses the mutative action 'Clear all in-memory flows' and optional proxy stop, but lacks details on whether flows are recoverable, impact on saved flows, or side effects on proxy state. This is inadequate for a destructive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action, no redundant words. Every bit of text serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (not shown), the description fails to contextualize what happens after clearing: success indication, number of cleared flows, or any confirmation. It also does not tie into sibling tools (e.g., flows_list to verify clearing). Incomplete for a state-changing operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning to the stop_proxy parameter by stating 'Optionally stop the proxy too'. This clarifies the parameter's effect beyond the schema's title. However, it does not explain the default or behavior when not set. A 3 is appropriate as it adds value but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Clear' and resource 'all in-memory flows', which is specific and distinguishes from siblings like flow_delete (single flow) or flows_list. However, it does not explicitly differentiate from other clearing tools, but the name and context suffice for a 4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like flow_delete or flows_load. The only usage hint is the optional proxy stop, but no context about prerequisites or scenarios where clearing flows is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List captured flows with optional filtering and pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | ||
| limit | No | ||
| host | No | ||
| method | No | ||
| status | No | ||
| search | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states 'List captured flows with optional filtering and pagination', which implies a safe read operation, but it does not detail critical behaviors like default pagination limits, how filtering logic works (AND/OR), what happens on empty results, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise—a single sentence without fluff. It front-loads the core action. However, for a tool with six parameters, slightly more structure (e.g., mentioning defaults or filter logic) could improve clarity without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has six parameters, no annotations, and no schema descriptions, the description is incomplete. It does not mention pagination defaults (offset, limit), filter combination logic, output structure (though an output schema exists), or any usage constraints. The description is insufficient for an agent to use the tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no parameter documentation. The description vaguely mentions 'optional filtering and pagination', but does not explain what the filtering parameters (host, method, status, search) represent or how they interact. The parameter names are somewhat self-explanatory, but the description adds minimal semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists captured flows, which is a specific verb+resource. It mentions optional filtering and pagination, adding value beyond the name. However, it does not explicitly distinguish from sibling tools like flow_get or flows_clear, though the name 'flows_list' already hints at listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as flow_get or flows_clear. The description lacks context about prerequisites, appropriate scenarios, or limitations, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load flows from a .mitm file into memory.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It only states 'load into memory' without specifying whether existing flows are replaced or appended, or if there are side effects on the current state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no wasted words. It front-loads the essential information. A bit more structure (e.g., stating 'To restore previously saved flows') could improve clarity but not required for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter and no annotations, the description is minimally adequate. The output schema exists but is not shown; if it defines return values, the description need not explain them. Still, it lacks details on behavior (overwrite/append) and error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaning beyond the schema by specifying the file type (.mitm). However, it does not specify path constraints (local/URL), valid file extensions, or default behavior if the path is invalid.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'load', the resource 'flows', and the file format '.mitm'. This distinguishes it from sibling tools like flows_save (save to file) and flows_list (list flows).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. There is no mention of prerequisites (e.g., file must exist) or situations where other tools like 'flows_create' or 'flows_list' are preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save all in-memory flows to a .mitm file.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It states that all in-memory flows are saved to a .mitm file, but it does not reveal critical behavioral traits such as whether the tool overwrites an existing file, requires directory existence, or has side effects (e.g., clearing in-memory flows). This lack of detail creates significant gaps for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 10 words with no unnecessary information. It is maximally concise and front-loads the core action and resource. Every word contributes to understanding the tool's primary function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no nested objects, output schema present), the description provides adequate high-level purpose but lacks details on side effects, return format, and file handling. It is sufficient for a basic understanding but not fully complete for confident invocation without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds only minimal semantics by implying that the 'path' parameter should point to a .mitm file. It fails to specify path format (absolute/relative), required directory permissions, or restrictions like needing a file path versus directory. More detail is needed for a single required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Save all in-memory flows to a .mitm file' uses a specific verb ('save') and clearly identifies the resource ('all in-memory flows') and output format ('.mitm file'). It effectively distinguishes this tool from siblings like flows_load, flows_clear, and flows_list by specifying the save-to-file action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: if you want to persist flows to a file, use this tool. However, it provides no explicit guidance on when to use it versus alternatives (e.g., flows_load for loading, flows_clear for clearing), nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Modify a captured request/response and its metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| flow_id | Yes | ||
| request_method | No | ||
| request_path | No | ||
| request_headers | No | ||
| request_body | No | ||
| request_body_encoding | No | text | |
| response_status | No | ||
| response_reason | No | ||
| response_headers | No | ||
| response_body | No | ||
| response_body_encoding | No | text | |
| comment | No | ||
| marked | No | ||
| tags | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only implies mutation ('Modify') but does not disclose what aspects are modifiable, whether changes are reversible, side effects on other operations, or any requirements (e.g., authentication). With no annotations, the description fails to provide necessary behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) but sacrifices completeness for brevity. It is front-loaded with the verb and resource but lacks critical details for a tool with many parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 14 parameters, no schema descriptions, no annotations, and a laconic description, the tool definition is incomplete. The output schema exists but is not shown, so the agent lacks information on return values. The description does not cover the complexity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not elaborate on any of the 14 parameters. While parameter names are somewhat self-explanatory (e.g., 'Request Method'), the description adds no semantic value beyond the schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Modify' and the resource 'a captured request/response and its metadata', effectively distinguishing it from sibling tools like flow_create (create), flow_delete (delete), and flow_get (get).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided regarding when to use this tool versus alternatives (e.g., flow_create for new flows, flow_replay for replaying). There is no mention of prerequisites, limitations, or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start the mitmproxy capture proxy.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | 127.0.0.1 | |
| port | No | ||
| capture_filter | No | ||
| ssl_insecure | No | ||
| upstream_proxy | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, and the description fails to disclose behavioral traits such as blocking behavior, side effects, permissions, error states, or impact on existing proxy instances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short single sentence, but it is under-specification rather than concise. It does not efficiently convey important details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is insufficient given five parameters, no annotations, and an output schema. It fails to explain return values, configuration, or usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description provides no explanation of the 5 parameters (host, port, capture_filter, etc.). The schema only gives defaults and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Start the mitmproxy capture proxy,' which is a specific verb+resource. It distinguishes from siblings like proxy_status and proxy_stop. However, it lacks details about mitmproxy's role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like proxy_stop or flow tools. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current proxy status and number of captured flows.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description bears full burden. It clearly denotes a read operation with no side effects, though it omits details like authentication or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description effectively states what is returned and covers the essential purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, and schema coverage is 100%. The description does not need to add param info, meeting the baseline for no-param tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets 'current proxy status and number of captured flows', specifying a distinct verb and resource. It stands apart from siblings like proxy_start and flows_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or when not to. The purpose is implied but without declaring alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop the mitmproxy capture proxy.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose behavioral traits such as whether stopping is immediate, if ongoing captures are lost, or if any confirmation is required. This is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant information. Every word is necessary and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema provided but present), the description is adequate for a basic stop action. However, it lacks context about the effect on current captures or system state, which would be helpful for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the input schema fully describes the expected input. The description does not need to add parameter meaning, and the baseline of 4 is appropriate since the tool requires no arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Stop') and the resource ('the mitmproxy capture proxy'), making it easy for the agent to understand the tool's purpose. It also implicitly distinguishes from sibling tools like 'proxy_start' (which starts the proxy) and 'proxy_status' (which checks status).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool or when not to use it. Usage is implied (stop the proxy when it's running), but no alternatives or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a new HTTP request using mitmproxy's built-in replay.client.
| Name | Required | Description | Default |
|---|---|---|---|
| method | Yes | ||
| url | Yes | ||
| headers | No | ||
| body | No | ||
| body_encoding | No | text |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for disclosing behavioral traits. It only mentions 'using mitmproxy's built-in replay.client' but does not explain side effects (e.g., that it actually sends a live HTTP request, modifies state, or requires specific permissions). No warnings about potential rate limits or destructive actions are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, but it could be more structured. It uses one sentence and does not waste words, but it lacks a clear breakdown of tool purpose, usage, or parameters. It is adequate but not optimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (5 parameters, no schema coverage, and a boolean output schema), the description is incomplete. It does not explain the boolean return value (e.g., success/failure), nor does it provide context about the 'replay.client' mechanism or any prerequisites. The presence of an output schema mitigates some need for return value explanation, but overall completeness is low.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning beyond the schema. It does not explain the role of 'method', 'url', 'headers', 'body', or 'body_encoding'. The schema provides basic types and titles, but the description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send a new HTTP request') and the resource ('new HTTP request'), and it implicitly distinguishes from sibling tools like 'flow_replay' which replays existing flows. The verb 'Send' and object 'new HTTP request' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., flow_replay for replaying captured flows, flow_create for creating flows from scratch). There is no mention of prerequisites, such as requiring the mitmproxy proxy to be running, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0flow_createflow_deleteflow_getflow_replayflow_updateflows_clearflows_listflows_loadflows_saveproxy_startproxy_statusproxy_stoprequest_sendEach tool targets a distinct operation: proxy lifecycle management, flow singular vs plural actions, and request sending. Descriptions clearly differentiate between creating a flow without sending versus sending a request.
All tool names follow a consistent prefix_verb pattern with underscores (e.g., proxy_start, flows_list, flow_update). Singular vs plural prefixes are used appropriately for single vs batch operations.
13 tools cover proxy management, flow CRUD, load/save, replay, and request sending without unnecessary overlap. The scope aligns well with the mitmproxy domain.
The set covers the full lifecycle: proxy start/stop/status, flow capture, retrieval, creation, modification, deletion, persistence, and replay/send. No obvious gaps for standard proxy operations.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
MCP server for building and testing AI agents with multi-model experimentation and insights.
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/u33pk/mitmproxy-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
