What can you do with this server?

proxy-mcp is an HTTP/HTTPS MITM proxy MCP server for intercepting, modifying, and analyzing network traffic, with advanced TLS fingerprinting, browser automation, and multi-platform device routing. Core Proxy * Start/stop the proxy with auto-generated CA certificates; retrieve PEM/SPKI fingerprint for device trust installation * Capture traffic in memory (1000 entries) or persistent on-disk sessions * List, search, filter, and inspect captured HTTP exchanges (URL, hostname, method, status, full-text body search) Interception Rules * Add/update/remove/enable/disable rules with matchers (URL, hostname, method, headers, body) and handlers (passthrough, mock, forward, drop) * Transform traffic in-flight: inject/delete headers, rewrite URLs, replace bodies, change status codes * Test rules against simulated or captured exchanges with per-field diagnostics TLS Fingerprinting & Spoofing * Capture JA3/JA4 client and JA3S server fingerprints per exchange * Spoof outgoing TLS ClientHello, HTTP/2 frames, and header order using browser presets (Chrome 131/136, Firefox 133+) via native Rust impit * Normalize UA Client Hints to match spoofed User-Agent Upstream Proxy Chaining * Global or per-host upstream proxies (SOCKS4/5, HTTP, HTTPS, PAC) for geo-routing, authentication, or IP reputation * Bypass lists (no_proxy) for both global and per-host configs Browser Interception (cloakbrowser) * Launch stealth-patched Chromium with proxy flags and CA trust auto-configured * Navigate pages, take ARIA/role YAML snapshots and screenshots, read console messages * List/retrieve cookies, localStorage, sessionStorage, and proxy-captured network headers * TLS ClientHello passthrough: browser's native ClientHello forwarded upstream for authentic Chrome TLS fingerprints Human-like Browser Automation * Mouse movement via Bezier curves with Fitts's law velocity scaling * Click by CSS selector, ARIA role/name, visible text, or form label (with auto-wait) * Typing with WPM-based timing, bigram frequency modeling, optional typos with backspace correction * Scrolling with easeInOutQuad acceleration; idle simulation with micro-jitter and micro-scrolls Terminal / Process Interception * Spawn processes with proxy env vars pre-configured (HTTP_PROXY, HTTPS_PROXY, SSL_CERT_FILE, NODE_EXTRA_CA_CERTS, CURL_CA_BUNDLE, and 15+ more) Android Interception * Full device interception via ADB: CA cert injection into system store, ADB reverse tunnel, optional Wi-Fi proxy * Frida-based SSL unpinning: attach to running apps with unpinning + proxy redirect scripts, bypassing certificate pinning Docker Interception * Inject proxy env vars and CA cert into running containers (live exec or stop+restart mode) Persistent Sessions & HAR * Start/stop/query persistent sessions with preview or full-body capture * Import HAR files for analysis and replay; export sessions to HAR * Replay recorded requests in dry-run or execute mode with optional target URL override * Recover/rebuild session indexes after crash or corruption

Which integrations are available for this server?

Provides comprehensive traffic interception for Android devices, including CA certificate injection via ADB, reverse tunneling, and SSL unpinning using Frida scripts. Enables automated launching of the Brave browser with integrated proxy configuration for capturing and modifying web traffic. Automates proxy configuration for curl commands by setting environment variables to route traffic through the MITM proxy for inspection. Supports intercepting Deno network traffic by automatically configuring proxy environment variables for spawned processes. Injects proxy settings and CA certificates into running Docker containers to capture and inspect containerized network traffic. Enables monitoring and manipulation of Git network requests by automatically configuring proxy environment variables. Allows for the interception of Node.js network traffic by configuring proxy environment variables and SSL certificate trust for spawned processes. Routes npm network activity through the proxy by setting appropriate environment variables to capture and inspect package management traffic. Enables interception of Python application traffic, including support for the requests library, through automated environment variable injection. Routes yarn network activity through the proxy by setting appropriate environment variables to capture and inspect package management traffic.

How do I use proxy-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@proxy-mcp intercept traffic to api.example.com and show the headers" 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.

de en es ja ko ru zh

proxy-mcp

by yfe404

Overview Schema Related Servers Score Discussions

TypeScript

Local

proxy-mcp is an HTTP/HTTPS MITM proxy MCP server for intercepting, modifying, and analyzing network traffic, with advanced TLS fingerprinting, browser automation, and multi-platform device routing.

Core Proxy

Start/stop the proxy with auto-generated CA certificates; retrieve PEM/SPKI fingerprint for device trust installation
Capture traffic in memory (1000 entries) or persistent on-disk sessions
List, search, filter, and inspect captured HTTP exchanges (URL, hostname, method, status, full-text body search)

Interception Rules

Add/update/remove/enable/disable rules with matchers (URL, hostname, method, headers, body) and handlers (passthrough, mock, forward, drop)
Transform traffic in-flight: inject/delete headers, rewrite URLs, replace bodies, change status codes
Test rules against simulated or captured exchanges with per-field diagnostics

TLS Fingerprinting & Spoofing

Capture JA3/JA4 client and JA3S server fingerprints per exchange
Spoof outgoing TLS ClientHello, HTTP/2 frames, and header order using browser presets (Chrome 131/136, Firefox 133+) via native Rust impit
Normalize UA Client Hints to match spoofed User-Agent

Upstream Proxy Chaining

Global or per-host upstream proxies (SOCKS4/5, HTTP, HTTPS, PAC) for geo-routing, authentication, or IP reputation
Bypass lists (no_proxy) for both global and per-host configs

Browser Interception (cloakbrowser)

Launch stealth-patched Chromium with proxy flags and CA trust auto-configured
Navigate pages, take ARIA/role YAML snapshots and screenshots, read console messages
List/retrieve cookies, localStorage, sessionStorage, and proxy-captured network headers
TLS ClientHello passthrough: browser's native ClientHello forwarded upstream for authentic Chrome TLS fingerprints

Human-like Browser Automation

Mouse movement via Bezier curves with Fitts's law velocity scaling
Click by CSS selector, ARIA role/name, visible text, or form label (with auto-wait)
Typing with WPM-based timing, bigram frequency modeling, optional typos with backspace correction
Scrolling with easeInOutQuad acceleration; idle simulation with micro-jitter and micro-scrolls

Terminal / Process Interception

Spawn processes with proxy env vars pre-configured (HTTP_PROXY, HTTPS_PROXY, SSL_CERT_FILE, NODE_EXTRA_CA_CERTS, CURL_CA_BUNDLE, and 15+ more)

Android Interception

Full device interception via ADB: CA cert injection into system store, ADB reverse tunnel, optional Wi-Fi proxy
Frida-based SSL unpinning: attach to running apps with unpinning + proxy redirect scripts, bypassing certificate pinning

Docker Interception

Inject proxy env vars and CA cert into running containers (live exec or stop+restart mode)

Persistent Sessions & HAR

Start/stop/query persistent sessions with preview or full-body capture
Import HAR files for analysis and replay; export sessions to HAR
Replay recorded requests in dry-run or execute mode with optional target URL override
Recover/rebuild session indexes after crash or corruption

proxy-mcp

proxy-mcp is an MCP server that runs an explicit HTTP/HTTPS MITM proxy (L7). It captures requests/responses, lets you modify traffic in-flight (headers/bodies/mock/forward/drop), supports upstream proxy chaining, and records TLS fingerprints for connections to the proxy (JA3/JA4) plus optional upstream server JA3S. Ships "interceptors" to route stealth browsers (cloakbrowser and Camoufox), CLI tools, Docker containers, and Android devices/apps through the proxy, plus Playwright-driven browser automation with locator-based click, typing, scroll, and ARIA snapshots.

74 tools + 8 resources + 3 resource templates. Built on mockttp, cloakbrowser, and Camoufox.

IMPORTANT

proxy-mcp is no longer published to npmjs. npm's publishing system has become too annoying to be worth it — expiring tokens that silently break releases, and a mandatory passkey/2FA enrollment maze just to change a package setting. Distribution now happens directly from this repository:

npx -y "github:yfe404/proxy-mcp#semver:^3"

Versions ≤ 3.3.2 remain on npmjs but will never be updated — npx -y proxy-mcp@latest silently stays stale. Update your MCP config to the GitHub form above. See Setup.

Related MCP server: Android Proxy MCP

Setup

Quick install (Claude Code)

claude mcp add proxy-mcp -- npx -y "github:yfe404/proxy-mcp#semver:^3"

This installs proxy-mcp as an MCP server using stdio transport, straight from GitHub — no registry involved. The #semver:^3 range resolves against this repo's version tags, so new releases are picked up automatically.

Note: the first install compiles from source (a prepare build), so it takes a few seconds longer than a registry tarball — subsequent launches use the npx cache. Why not npmjs anymore? See the announcement at the top: their publishing system got too annoying.

Scopes:

# Per-user (available in all projects)
claude mcp add --scope user proxy-mcp -- npx -y "github:yfe404/proxy-mcp#semver:^3"

# Per-project (shared via .mcp.json, commit to repo)
claude mcp add --scope project proxy-mcp -- npx -y "github:yfe404/proxy-mcp#semver:^3"

To pin an exact release instead, use github:yfe404/proxy-mcp#v3.4.0.

Prerequisites

Node.js 20+

From source (development)

git clone https://github.com/yfe404/proxy-mcp.git
cd proxy-mcp
npm install
npm run build

# stdio transport (default) — used by MCP clients like Claude Code
node dist/index.js

# Streamable HTTP transport — exposes /mcp endpoint for scripting
node dist/index.js --transport http --port 3001

--transport and --port also accept env vars TRANSPORT and PORT.

PROXY_MCP_UPSTREAM_PASSWORD and PROXY_MCP_UPSTREAM_HOST keep an upstream proxy password out of the transcript — see Keeping the upstream password out of the transcript.

Manual MCP configuration

The configured server alias controls Claude's generated tool prefix. The examples below use proxy-mcp, so Claude Code exposes tools as mcp__proxy-mcp__<tool_name>. If you rename the server key to proxy, use mcp__proxy__<tool_name> instead.

Claude Code CLI:

# stdio (default)
claude mcp add proxy-mcp -- npx -y "github:yfe404/proxy-mcp#semver:^3"

# From local clone
claude mcp add proxy-mcp -- node /path/to/proxy-mcp/dist/index.js

# HTTP transport for scripting
claude mcp add --transport http proxy-mcp http://127.0.0.1:3001/mcp

.mcp.json (project-level, commit to repo):

{
  "mcpServers": {
    "proxy-mcp": {
      "command": "npx",
      "args": ["-y", "github:yfe404/proxy-mcp#semver:^3"]
    }
  }
}

Streamable HTTP transport:

{
  "mcpServers": {
    "proxy-mcp": {
      "type": "streamable-http",
      "url": "http://127.0.0.1:3001/mcp"
    }
  }
}

HTTP Proxy Configuration

1) Start proxy and get endpoint

proxy_start

Use the returned port and endpoint http://127.0.0.1:<port>.

2) Browser setup (recommended: interceptor)

Use the browser interceptor so proxy flags and cert trust are configured automatically. Launches cloakbrowser — a stealth-patched Chromium with source-level C++ fingerprint patches and humanize mode on by default:

interceptor_browser_launch --url "https://example.com"

Drive the page with Playwright-backed tools (no CDP, no sidecar — target_id is all you need):

interceptor_browser_navigate --target_id "browser_<id>" --url "https://apify.com"
interceptor_browser_snapshot  --target_id "browser_<id>"
interceptor_browser_screenshot --target_id "browser_<id>" --file_path "/tmp/shot.png"

3) Browser setup (manual fallback)

If launching a browser manually, pass the proxy flag yourself:

google-chrome --proxy-server="http://127.0.0.1:<port>"

4) CLI/process setup

Route any process through proxy-mcp by setting proxy env vars:

export HTTP_PROXY="http://127.0.0.1:<port>"
export HTTPS_PROXY="http://127.0.0.1:<port>"
export NO_PROXY="localhost,127.0.0.1"

If the client verifies TLS, trust the proxy-mcp CA certificate (see proxy_get_ca_cert) or use the Terminal interceptor (interceptor_spawn) which sets proxy env vars plus common CA env vars (curl, Node, Python requests, Git, npm/yarn, etc.):

interceptor_spawn --command curl --args '["-s","https://example.com"]'

Explicit curl examples:

curl --proxy http://127.0.0.1:<port> http://example.com
curl --proxy http://127.0.0.1:<port> https://example.com

5) Upstream proxy chaining

Set optional proxy chaining from proxy-mcp to another upstream proxy (for geolocation, auth, or IP reputation):

Client/app  →  proxy-mcp (local explicit proxy)  →  upstream proxy (optional chaining layer)

proxy_set_upstream --proxy_url "socks5://user:pass@upstream.example:1080"

Supported upstream URL schemes: socks4://, socks5://, http://, https://, pac+http://.

Keeping the upstream password out of the transcript

Tool calls and tool results are both persisted by the MCP client. To avoid writing an upstream password there on every call, set it in the server's environment and pass a URL with a username but no password.

Two variables are required, and both have to be in the environment of the server process, which the MCP client spawns. Exporting them in the shell you launch the client from may reach it — CLI clients pass their own environment through — but that depends on the client and is lost the moment the server is started any other way. Put them in the client's server config:

variable	meaning
`PROXY_MCP_UPSTREAM_PASSWORD`	the password to fill in
`PROXY_MCP_UPSTREAM_HOST`	the only hostname it may be sent to — a bare hostname, no scheme, port or path

claude mcp add proxy-mcp \
  -e PROXY_MCP_UPSTREAM_PASSWORD=s3cret \
  -e PROXY_MCP_UPSTREAM_HOST=upstream.example \
  -- npx -y "github:yfe404/proxy-mcp#semver:^3"

{
  "mcpServers": {
    "proxy-mcp": {
      "command": "npx",
      "args": ["-y", "github:yfe404/proxy-mcp#semver:^3"],
      "env": {
        "PROXY_MCP_UPSTREAM_PASSWORD": "s3cret",
        "PROXY_MCP_UPSTREAM_HOST": "upstream.example"
      }
    }
  }
}

Then omit the password from the call:

proxy_set_upstream --proxy_url "http://user@upstream.example:1080"
# routes as http://user:s3cret@upstream.example:1080

Why the host variable exists. Without it, a caller who cannot read the password could still name any host and have the password delivered there — the proxy sends it on the first request, and the transcript would show only ***. The hostname is matched case-insensitively and exactly, with no wildcards; the port is not part of the match, so one variable covers a provider offering several. A URL naming any other host is left alone. If PROXY_MCP_UPSTREAM_PASSWORD is set and PROXY_MCP_UPSTREAM_HOST is not, nothing is merged at all: a half-configuration fails closed rather than becoming an unbound credential.

This keeps the password out of tool arguments and responses, not out of reach. interceptor_spawn runs an arbitrary command as the server user, so a caller can read the client config file the password is configured in — and on Linux /proc/<pid>/environ. The variable removes the routine exposure of writing a credential into every tool call; it is not a sandbox, and anyone who can call interceptor_spawn should be treated as able to obtain the password.

The response reports which credential was used — passwordSource is env, url or none. proxy_mobile_setup spells it password_source, matching the snake_case of the rest of that tool's response. none means no password was applied to a URL that names a user: either the credential is genuinely username-only, or the server does not have both variables set for this host. The field is omitted for a URL with no username, where the question does not arise.

Applies to proxy_set_upstream, proxy_set_host_upstream and proxy_mobile_setup. A URL that already carries a password is used as-is, so existing calls are unaffected. One credential covers all upstreams at the pinned host; a URL without a username is left alone.

Username-only credentials at the pinned host cannot be expressed. A URL with a username and no password is exactly the syntax that requests the merge, and user:@host cannot signal otherwise — the URL parser erases the empty password before the server sees it. If the pinned host authenticates on the username alone, unset PROXY_MCP_UPSTREAM_PASSWORD for that server.

socks*:// upstreams: no : in the password. socks-proxy-agent splits the credential on the first : and keeps only what follows, so pa:ss would authenticate as pa. Rather than deliver half a password silently, a socks upstream is refused with an error when PROXY_MCP_UPSTREAM_PASSWORD contains :. The truncation itself is a toolchain limitation, not something this introduces — a literal socks5://user:pa%3Ass@host:1080 truncates the same way, and nothing can guard that. http://, https:// and pac+http:// upstreams take the whole password.

A : in the username is refused on every scheme. Basic auth splits the decoded pair at the first colon (RFC 7617), and socks-proxy-agent does the same, so a username of gro:ups with password s3cret reaches the proxy as user gro, password ups:s3cret — the merged password silently discarded. No scheme can carry it, so the merge refuses rather than guess. Put the whole credential in proxy_url instead.

Responses redact credentials — the password in userinfo, with path segments masked and the query and fragment dropped, since a pac+http:// token may live in any of those:

Global upstream set to http://user:***@upstream.example:1080/
Global upstream set to pac+http://pac.example.com/***

proxy_status and the proxy://status resource are redacted the same way. A PAC URL's filename is masked along with the rest of the path, so a confirmation message shows the host and nothing else.

The username is not redacted. For several providers it is configuration rather than a secret — Apify Proxy encodes proxy group, country and sticky-session id there — and showing it is what makes the confirmation useful. If your provider puts a secret in the username field, do not rely on these messages being safe to share.

Typical geo-routing examples:

# Route ALL outgoing traffic from proxy-mcp via a geo proxy
proxy_set_upstream --proxy_url "socks5://user:pass@fr-exit.example.net:1080"

# Bypass upstream for local/internal hosts
proxy_set_upstream --proxy_url "http://user:pass@proxy.example.net:8080" --no_proxy '["localhost","127.0.0.1",".corp.local"]'

# Route only one hostname via a dedicated upstream (overrides global)
proxy_set_host_upstream --hostname "api.example.com" --proxy_url "https://user:pass@us-exit.example.net:443"

# Remove overrides when done
proxy_remove_host_upstream --hostname "api.example.com"
proxy_clear_upstream

For HTTPS MITM, the proxy CA must be trusted in the target environment (proxy_get_ca_cert).

6) Validate and troubleshoot quickly

proxy_list_traffic --limit 20
proxy_search_traffic --query "example.com"

Common issues:

Traffic from the wrong browser instance (fix: always pass target_id from interceptor_browser_launch)
HTTPS cert trust missing on target
NO_PROXY bypassing expected hosts
First launch is slow: cloakbrowser downloads a ~200 MB stealth Chromium binary on first use (cached afterwards)

7) HAR import + replay

Import HAR into a persisted session, then analyze with existing session query/findings tools:

proxy_import_har --har_file "/path/to/capture.har" --session_name "imported-run"
proxy_list_sessions
proxy_query_session --session_id SESSION_ID --hostname_contains "api.example.com"
proxy_get_session_handshakes --session_id SESSION_ID

Replay defaults to dry-run (preview only). Execute requires explicit mode:

# Preview what would be replayed
proxy_replay_session --session_id SESSION_ID --mode dry_run --limit 20

# Execute replay against original hosts
proxy_replay_session --session_id SESSION_ID --mode execute --limit 20

# Optional: override target host/base URL while preserving path+query
proxy_replay_session --session_id SESSION_ID --mode execute --target_base_url "http://127.0.0.1:8081"

Note: imported HAR entries (and entries created by proxy_replay_session) do not carry JA3/JA4/JA3S handshake metadata. Use live proxy-captured traffic to analyze handshake fingerprints.

Mobile Capture (Transparent Proxy)

For mobile apps with custom HTTP stacks that ignore the system proxy (most modern Android apps — Shopee, SHEIN, TikTok, banking, etc.) the explicit proxy won't see their traffic. proxy-mcp ships a transparent listener that sits behind an iptables REDIRECT and MITMs using the TLS SNI — no CONNECT tunnel required.

Pairs with proxy-ap-card — a XIAO ESP32-S3 that broadcasts a WiFi AP (proxy-ap SSID by default) and presents to the laptop as a USB-NCM ethernet adapter. That repo handles the AP + NAPT side; proxy-mcp handles the laptop side.

Prerequisites

Laptop: Linux with iptables, sysctl, nmcli (NetworkManager), ip (iproute2), adb. sudo for network configuration (one command per session).
Hardware router: a proxy-ap-card (XIAO ESP32-S3) with firmware flashed. Or any USB-ethernet / USB-WiFi combo where the laptop NATs traffic for the phone's subnet — pass --ap_iface / --ap_subnet to override defaults.
Target device: Android with root (Magisk / KernelSU). Root is required to inject the CA into the system cert store. Android 14-16 additionally need the zygote mount-namespace injection which this tool does automatically.
ADB access: the target device must appear in adb devices (USB at minimum, wireless after pairing).

First-time walkthrough

1. Flash + plug in the proxy-ap-card

Follow the proxy-ap-card README to build + flash the XIAO. On replug the laptop should show a cdc_ncm interface (verify: ls /sys/class/net/*/device/uevent | xargs grep DRIVER | grep cdc_ncm).

2. Connect the target device to the laptop via USB

Only needed the first time per device, to push the CA. Verify with adb devices. Copy the serial.

3. Run the setup tool

proxy_mobile_setup --android_serial <serial>

Optional arguments:

Param	Default	When to override
`ap_iface`	auto-detect (`cdc_ncm`)	Using a different USB-ethernet bridge
`ap_address`	`192.168.99.2/24`	Matches default proxy-ap-card firmware
`ap_subnet`	`192.168.4.0/24`	Matches default proxy-ap-card firmware
`egress_iface`	auto-detect from default route	Multi-homed host, or wanting traffic to exit via a specific iface
`explicit_port`	`8080`	Port collision
`transparent_port`	`8443`	Port collision
`block_quic`	`true`	Need QUIC/HTTP3 (no MITM available then)
`upstream_proxy_url`	—	Route outbound through a residential/ISP proxy — see below
`android_serial`	—	Omit to skip CA injection (remote-only setups)
`inject_cert`	`true` if `android_serial` set	Set `false` to re-use a prior install

The response is JSON with three key bits:

{
  "ap_iface": "enp195s0f3u1u4",
  "cert_injected": true,
  "android_target_id": "adb_HQ63C81CB2",
  "sudo_command": "sudo bash /tmp/proxy-mcp-mobile-setup-<hex>.sh"
}

Keep android_target_id around — you'll need it for teardown.

4. Run the emitted sudo script

sudo bash /tmp/proxy-mcp-mobile-setup-<hex>.sh

This is the only sudo required. The script is idempotent, safe to re-run. It plumbs the routing that iptables needs root for:

# Static IP on the AP iface (skipped if already configured).
ip addr add 192.168.99.2/24 dev <ap_iface>

# Forwarding + dedicated nat chain.
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -N PROXY_MCP_PREROUTING
iptables -t nat -A PROXY_MCP_PREROUTING -p tcp --dport 80  -j REDIRECT --to-ports 8080
iptables -t nat -A PROXY_MCP_PREROUTING -p tcp --dport 443 -j REDIRECT --to-ports 8443
iptables -t nat -A PREROUTING -i <ap_iface> -j PROXY_MCP_PREROUTING

# Block QUIC so apps fall back to TCP/TLS.
iptables -A FORWARD -i <ap_iface> -p udp --dport 443 -j DROP

# Masquerade out through the real egress.
iptables -t nat -A POSTROUTING -s 192.168.4.0/24 -o <egress_iface> -j MASQUERADE

Why a script and not direct execution? MCP runs as your user; iptables needs root; sudo from an MCP tool would require NOPASSWD or polkit policy (fragile, distro-specific). Emitting a script is auditable, reproducible, and portable.

5. Connect the phone to the `proxy-ap` WiFi

Credentials are set in the proxy-ap-card firmware (default SSID proxy-ap, default password shown in that repo). After connecting, the phone can be unplugged from USB — future sessions don't need it.

6. Start capturing

Every HTTP/HTTPS request from the phone now lands in proxy-mcp's ring buffer:

proxy_list_traffic --source_filter transparent   # iptables-redirected HTTPS
proxy_list_traffic --source_filter explicit      # absolute-URL HTTP that arrived on :80
proxy_get_exchange --exchange_id <id>            # full headers + body preview
proxy_search_traffic --query "api.example.com"   # full-text search

Each entry carries source: "explicit" | "transparent" + TLS fingerprints (ja3, ja4).

Subsequent sessions (phone already paired)

Skip step 2. Run:

proxy_mobile_setup                                # skip android_serial — cert already installed
sudo bash /tmp/proxy-mcp-mobile-setup-<hex>.sh

Then phone joins the AP and capture resumes.

Upstream chaining

Set upstream_proxy_url to route outbound traffic through a residential/ISP proxy — the target servers see that proxy's IP, not your laptop's:

proxy_mobile_setup \
  --upstream_proxy_url "http://user:pass@proxy.example.com:8000" \
  --android_serial <serial>

Applies to BOTH listeners. Use proxy_set_upstream after the fact to change it without restarting.

As with proxy_set_upstream, omit the password and set PROXY_MCP_UPSTREAM_PASSWORD and PROXY_MCP_UPSTREAM_HOST in the server's environment to keep it out of the call.

Verifying each step

Check	Command	Expected
Listeners up	`proxy_status`	`running: true`, `transparentProxy.running: true`
Iface detected	`proxy_mobile_detect_iface`	`found: true`, iface name
Cert injected	`adb shell "su -c 'nsenter --mount=/proc/\$(pidof zygote64)/ns/mnt -- ls /apex/com.android.conscrypt/cacerts/ \| wc -l'"`	144 (or 143 + 1)
iptables wired	`sudo iptables -t nat -L PROXY_MCP_PREROUTING -v -n`	2 REDIRECT rules, non-zero `pkts` after phone generates traffic
Forwarding on	`cat /proc/sys/net/ipv4/ip_forward`	`1`
Phone sees AP	phone Settings → WiFi shows `proxy-ap` connected, IP in `192.168.4.0/24`
Traffic flowing	`proxy_list_traffic --limit 5` after opening any app	`source: "transparent"` entries with status 200

Teardown

proxy_mobile_teardown --android_target_id <from-setup>
sudo bash /tmp/proxy-mcp-mobile-teardown-<hex>.sh

The MCP call stops both listeners and deactivates the Android target. The sudo script removes the iptables rules, disables ip_forward, and hands the AP iface back to NetworkManager. Phone stays connected to the AP until you forget it in phone WiFi settings.

Troubleshooting

Symptom	Likely cause	Fix
`proxy_mobile_detect_iface` returns `found: false`	proxy-ap-card not plugged in, or `cdc_ncm` driver missing	`lsusb \| grep '303a:'`; `dmesg \| grep cdc_ncm`; re-plug the card
`setup` errors `No such file or directory: /sys/class/net/.../device/uevent`	iface name passed explicitly but doesn't exist	Use auto-detect or verify with `ip link`
Phone connects to AP but zero traffic in `proxy_list_traffic`	sudo script not run; or phone on a different WiFi	Verify `cat /proc/sys/net/ipv4/ip_forward` returns `1`; check phone's active SSID
Phone says "no internet" on `proxy-ap`	Forward + MASQUERADE rules missing, OR egress iface down	Re-run the sudo script; check `ip route show default`
HTTPS fails with "connection not private" or similar	Cert not trusted by the app (Chrome bundles its own CAs and ignores system trust, app has cert pinning)	Use another app to verify chain works; Chrome is the exception not the rule (see limitations below)
Some apps capture, others don't	Cert pinning in the apps that fail	See limitations below; Frida/LSPosed unpinning module needed
Ports 20346/20443/other custom ports not captured	Only `:80` and `:443` are redirected	Add extra REDIRECT rules in the sudo script, or pair redsocks to `CONNECT`-tunnel arbitrary ports through the explicit listener
`cert_injected: false` or zygote `nsenter` failed	Device not rooted, or SELinux `chcon` rejected	`adb shell su -c 'id'` must return `uid=0`; confirm `zygisksu` / Magisk is active
Wireless ADB port changes every session	Android's Wireless Debugging randomises the port	Re-pair; or keep phone plugged in for control plane

Without the proxy-ap-card

Any USB-NCM or USB-ethernet bridge that the phone can route through works:

proxy_mobile_setup --ap_iface eth1 --ap_address 10.0.0.1/24 --ap_subnet 10.0.0.0/24

Or use a laptop-hosted WiFi AP via hostapd on a USB WiFi adapter (MT76x2U, RTL8812AU, etc.) — pass the wlanN interface as ap_iface.

Limitations

Cert pinning — apps that pin specific public keys (Instagram, WhatsApp, banking, Shopee homepage feed, etc.) will refuse our mockttp cert even with CA trust installed. You see partial capture (tracking / static / unpinned endpoints succeed, pinned API calls fail). Fix: Frida or LSPosed unpinning module for that specific app. See interceptor_frida_attach in the tool reference, or morrownr's USB-WiFi guides for common patterns.
Chrome on Android — Chrome ships its own Mozilla CA bundle and enforces Certificate Transparency. Our CA is self-signed and not in any CT log, so Chrome rejects it regardless of system trust. Use any other app (or any OkHttp/Conscrypt-based browser) to verify the pipeline.
QUIC / HTTP3 — the transparent listener is TCP/TLS only. By default we drop UDP/443 so apps fall back to TCP. Set block_quic: false if you want QUIC to pass through uncaptured (QUIC content won't appear in traffic logs).
Non-standard ports — the default iptables rules only redirect TCP/80 and TCP/443. Shopee's :20346, custom gaming protocols, etc. will bypass. Add more REDIRECT rules in the sudo script (or chain redsocks to issue CONNECT tunnels through the explicit listener).
Native TLS pinning — some apps use BoringSSL/OpenSSL directly via JNI with pins embedded in the .so. Java-layer Frida hooks won't catch these; native hooks needed.
Root required — the system-trust CA overlay requires root. Non-rooted Android only trusts user-installed CAs for apps that explicitly opt in via network_security_config — which no shipping app does. There's no bypass for that without root.

Boundaries

Only sees traffic configured to route through it (not a network tap or packet sniffer)
Spoofs outgoing JA3 + HTTP/2 fingerprint + header order (via impit — native Rust TLS impersonation), not JA4 (JA4 is capture-only)
Can add, overwrite, or delete HTTP headers; outgoing header order can be controlled via fingerprint spoofing
Returns its own CA certificate — does not expose upstream server certificate chains

TLS ClientHello Passthrough (browser via interceptor)

When cloakbrowser is launched via interceptor_browser_launch, proxy-mcp forwards the browser's original TLS ClientHello to the upstream server for document loads and same-origin sub-resource requests. The target server sees an authentic Chrome TLS fingerprint — not the proxy's.

This is a key difference from typical MITM proxies (mitmproxy, Charles, Fiddler) which re-terminate TLS with their own fingerprint, making MITM trivially detectable by anti-bot systems via JA3/JA4 analysis.

How to verify passthrough is working:

proxy_list_tls_fingerprints --hostname_filter "example.com"

JA3 varies across requests to the same host — this is expected; Chrome randomizes cipher suite order per-connection (feature since Chrome 110+)
JA4 stays stable — same cipher/extension set, just different ordering
JA3 variation + JA4 stability = authentic Chrome TLS passthrough confirmed

When passthrough applies vs. when spoofing is needed:

Traffic source	TLS behavior	Action needed
cloakbrowser via `interceptor_browser_launch` (document loads, same-origin)	Browser's native ClientHello forwarded (passthrough)	None — fingerprint is authentic
cloakbrowser via `interceptor_browser_launch` (cross-origin sub-resources, when spoof active)	Re-issued via impit with spoofed TLS	`proxy_set_fingerprint_spoof` with a browser preset
Non-browser clients (curl, Python, `interceptor_spawn`)	Proxy's own TLS	`proxy_set_fingerprint_spoof` or `proxy_set_ja3_spoof` required
HAR replay (`proxy_replay_session`)	Proxy's own TLS	`proxy_set_fingerprint_spoof` required

Built on stealth browsers + Playwright

Browser automation uses cloakbrowser for stealth-patched Chromium and Camoufox for anti-detect Firefox, both driven through Playwright. There is no CDP sidecar or hand-rolled stealth script in proxy-mcp. Downstream tools take a browser_* target from interceptor_browser_launch or a camoufox_* target from interceptor_camoufox_launch.

Capability	proxy-mcp
See/modify DOM, run JS in page	`interceptor_browser_evaluate` (run JS file, return value), `interceptor_browser_inject_init_script` (pre-document hook, every navigation), `interceptor_browser_add_script_tag` (DOM-visible — avoid for stealth); plus `interceptor_browser_snapshot` for ARIA reads
Read cookies, localStorage, sessionStorage	Yes — `interceptor_browser_list_cookies`, `interceptor_browser_list_storage_keys`
Capture HTTP request/response bodies	Via the MITM proxy (4 KB preview cap by default; `full` capture profile on persisted sessions stores complete bodies)
Modify requests in-flight (headers, body, mock, drop)	Yes (declarative rules, hot-reload)
Upstream proxy chaining (geo, auth)	Global + per-host upstreams across all clients (SOCKS4/5, HTTP, HTTPS, PAC)
TLS fingerprint capture (JA3/JA4/JA3S)	Yes
JA3 + HTTP/2 fingerprint spoofing	Proxy-side (impit re-issues matching requests with spoofed TLS 1.3, HTTP/2 frames, and header order)
Intercept non-browser traffic (curl, Python, Android apps)	Yes (interceptors)
Human-like mouse/keyboard/scroll input	`humanizer_` tools call Playwright mouse/keyboard primitives on `browser_` and `camoufox_*` targets. Cloakbrowser's own humanize patches apply when enabled at launch; Camoufox cursor humanization follows its launch config.
Locator-based interaction	`humanizer_click` accepts CSS/XPath selector, ARIA role + name, visible text, or form label — no pixel guessing

Standard flow:

Call proxy_start
Optionally enable outbound fingerprint spoofing for cross-origin sub-resources: proxy_set_fingerprint_spoof --preset chrome_136
Call interceptor_browser_launch --url "https://example.com" or interceptor_camoufox_launch
Drive the page: interceptor_browser_navigate, interceptor_browser_snapshot, humanizer_click --selector "...", humanizer_type --text "..."
Inspect traffic: proxy_search_traffic --query "<hostname>"

Tools Reference

Lifecycle (4)

Tool	Description
`proxy_start`	Start MITM proxy, auto-generate CA cert
`proxy_stop`	Stop proxy (traffic/cert retained)
`proxy_status`	Running state, port, rule/traffic counts
`proxy_get_ca_cert`	CA certificate PEM + SPKI fingerprint

Transparent / Mobile Capture (6)

Tool	Description
`proxy_start_transparent`	Start second MITM listener (SNI-based, no CONNECT) on a parallel port; shares CA + rules + ring buffer with the explicit listener
`proxy_stop_transparent`	Stop the transparent listener
`proxy_transparent_status`	Running state + port + dedicated traffic count
`proxy_mobile_setup`	One-command mobile capture: start both listeners, inject CA into Android system store via adb (tmpfs overlay + zygote ns for Android 14+), emit a sudo-runnable iptables/sysctl/nmcli script
`proxy_mobile_teardown`	Reverse setup: deactivate Android target, stop transparent listener, emit teardown script
`proxy_mobile_detect_iface`	Probe `/sys/class/net` for a `cdc_ncm` USB interface (matches the proxy-ap-card firmware)

Upstream Proxy (4)

Tool	Description
`proxy_set_upstream`	Set global upstream proxy
`proxy_clear_upstream`	Remove global upstream
`proxy_set_host_upstream`	Per-host upstream override
`proxy_remove_host_upstream`	Remove per-host override

Interception Rules (7)

Tool	Description
`proxy_add_rule`	Add rule with matcher + handler
`proxy_update_rule`	Modify existing rule
`proxy_remove_rule`	Delete rule
`proxy_list_rules`	List all rules by priority
`proxy_test_rule_match`	Test which rules would match a simulated request or captured exchange, with detailed diagnostics
`proxy_enable_rule`	Enable a disabled rule
`proxy_disable_rule`	Disable without removing

Quick debugging examples:

# Simulate a request and see which rule would win
proxy_test_rule_match --mode simulate --request '{"method":"GET","url":"https://example.com/api/v1/items","headers":{"accept":"application/json"}}'

# Evaluate a real captured exchange by ID
proxy_test_rule_match --mode exchange --exchange_id "ex_abc123"

Traffic Capture (4)

Tool	Description
`proxy_list_traffic`	Paginated traffic list with filters
`proxy_get_exchange`	Full exchange details by ID
`proxy_search_traffic`	Full-text search across traffic
`proxy_clear_traffic`	Clear capture buffer

Modification Shortcuts (3)

Tool	Description
`proxy_inject_headers`	Add/overwrite/delete headers on matching traffic (set value to `null` to remove a header)
`proxy_rewrite_url`	Rewrite request URLs
`proxy_mock_response`	Return mock response for matched requests

TLS Fingerprinting (9)

Tool	Description
`proxy_get_tls_fingerprints`	Get JA3/JA4 client fingerprints + JA3S for a single exchange
`proxy_list_tls_fingerprints`	List unique JA3/JA4 fingerprints across all traffic with counts
`proxy_set_ja3_spoof`	Legacy: enable JA3 spoofing (deprecated, use `proxy_set_fingerprint_spoof`)
`proxy_clear_ja3_spoof`	Disable fingerprint spoofing
`proxy_get_tls_config`	Return current TLS config (server capture, JA3 spoof state)
`proxy_enable_server_tls_capture`	Toggle server-side JA3S capture (monkey-patches `tls.connect`)
`proxy_set_fingerprint_spoof`	Enable full TLS + HTTP/2 fingerprint spoofing via impit. Supports browser presets.
`proxy_list_fingerprint_presets`	List available browser fingerprint presets (e.g. `chrome_131`, `chrome_136`, `chrome_136_linux`, `firefox_133`)
`proxy_check_fingerprint_runtime`	Check fingerprint spoofing backend readiness

Fingerprint spoofing works by re-issuing the request from the proxy via impit (native Rust TLS/HTTP2 impersonation via rustls). TLS 1.3 and HTTP/2 fingerprints (SETTINGS, WINDOW_UPDATE, PRIORITY frames) match real browsers by construction. The origin server sees the proxy's spoofed TLS, HTTP/2, and header order — not the original client's. When a user_agent is set (including via presets), proxy-mcp also normalizes Chromium UA Client Hints headers (sec-ch-ua*) to match the spoofed User-Agent (forwarding contradictory hints is a common bot signal). Browser exception: when cloakbrowser is launched via interceptor_browser_launch, document loads and same-origin requests use the browser's native TLS (no impit), preserving fingerprint consistency for bot detection challenges. Only cross-origin sub-resource requests are re-issued with spoofed TLS. Non-browser clients (curl, spawn, HAR replay) get full TLS + UA spoofing on all requests. Use proxy_set_fingerprint_spoof with a browser preset for one-command setup. proxy_set_ja3_spoof is kept for backward compatibility but custom JA3 strings are ignored (the preset's impit browser target is used instead). JA4 fingerprints are captured (read-only) but spoofing is not supported.

Interceptors (21)

Interceptors configure targets (browsers, processes, devices, containers) to route their traffic through the proxy automatically.

Discovery (3)

Tool	Description
`interceptor_list`	List all interceptors with availability and active target counts
`interceptor_status`	Detailed status of a specific interceptor
`interceptor_deactivate_all`	Emergency cleanup: kill all active interceptors across all types

Browser (3)

Tool	Description
`interceptor_browser_launch`	Launch cloakbrowser (stealth Chromium) with proxy flags, SPKI cert trust, built-in humanize mode
`interceptor_browser_navigate`	Navigate the bound page via Playwright `page.goto` and verify proxy capture
`interceptor_browser_close`	Close a browser instance by target ID

Stealth is source-level: cloakbrowser ships 48+ C++ patches so ja3n/ja4/akamai match real Chrome, navigator.webdriver is false, audio/canvas/WebGL fingerprints match real hardware. No JS stealth injection needed. First launch downloads a ~200 MB Chromium binary (cached afterwards).

Camoufox (4) — anti-detect Firefox

Tool	Description
`interceptor_camoufox_launch`	Spawn camoufox as a Playwright WebSocket server, proxy + NSS CA pre-wired. Returns `wsUrl`
`interceptor_camoufox_info`	Get the wsUrl + ready-to-paste TS / Python `firefox.connect()` snippets
`interceptor_camoufox_list`	List active camoufox instances and their fingerprint details
`interceptor_camoufox_close`	Stop the launcher, remove the temp launcher dir + NSS profile

Camoufox is a patched Firefox with source-level fingerprint controls (OS, WebGL vendor/renderer, fonts, locale, geoip-derived timezone, WebRTC blocking, humanize cursor). Camoufox runs as an external Python process and exposes a Playwright WS endpoint, but proxy-mcp also binds the returned camoufox_* target to the same interceptor_browser_* and humanizer_* tools used by cloakbrowser. Use the exposed wsUrl only when you need custom Playwright code outside MCP.

By default, proxy-mcp sets Camoufox fingerprint generation to the host OS (linux, macos, or windows) instead of Camoufox's upstream random OS list. Override with os when you intentionally need a different family, or pass an array such as ["windows", "macos"] to let Camoufox choose from that subset. Launch/list/info responses include a safe fingerprint summary with the resolved OS, User-Agent, platform, OSCPU, screen/window dimensions, WebGL vendor/renderer, and font/voice counts; raw Camoufox config and process environment are not exposed.

Host requirements:

pip install "cloverlabs-camoufox[geoip]"   # active fork; daijro/camoufox stale on Firefox 135 → DataDome distrusts
python3 -m camoufox fetch official/150.0.2-alpha.26   # Firefox 150; default `fetch` still picks v135 due to repos.yml constraint

# For TLS MITM trust (NSS profile is created per-launch and the proxy CA is imported):
sudo apt install libnss3-tools     # Debian/Ubuntu
sudo dnf install nss-tools         # Fedora/RHEL
# macOS: brew install nss   (or use /Applications/Firefox.app/Contents/MacOS/certutil)

If certutil is missing, the launch still succeeds but the proxy CA is not trusted — HTTPS pages will show certificate errors. Proxy traffic is still captured.

Usage:

proxy_start                                     // start the MITM proxy
interceptor_camoufox_launch { headless: true }  // returns { targetId, wsUrl, fingerprint, ... }
interceptor_browser_navigate --target_id "camoufox_<id>" --url "https://example.com"
interceptor_browser_snapshot --target_id "camoufox_<id>" --mode ai
interceptor_browser_list_console --target_id "camoufox_<id>"
interceptor_browser_list_cookies --target_id "camoufox_<id>"
// Or in your own Node code:
//   import { firefox } from 'playwright-core';
//   const browser = await firefox.connect(wsUrl);
//   const page = await (await browser.newContext()).newPage();
//   await page.goto('https://example.com');
interceptor_camoufox_close { target_id }        // when done

playwright-core is already a proxy-mcp dependency — Camoufox uses its firefox namespace via WebSocket; no extra Node packages needed. Traffic capture, TLS fingerprinting, rules, mocks, sessions, upstream chaining, and JA3/JA4 spoofing all apply to camoufox automatically because the proxy sits in front of it.

Terminal / Process (2)

Tool	Description
`interceptor_spawn`	Spawn a command with proxy env vars pre-configured (HTTP_PROXY, SSL certs, etc.)
`interceptor_kill`	Kill a spawned process and retrieve stdout/stderr

Sets 18+ env vars covering curl, Node.js, Python requests, Deno, Git, npm/yarn.

Android ADB (4)

Tool	Description
`interceptor_android_devices`	List connected Android devices via ADB
`interceptor_android_activate`	Full interception: inject CA cert, ADB reverse tunnel, optional Wi-Fi proxy
`interceptor_android_deactivate`	Remove ADB tunnel and clear Wi-Fi proxy
`interceptor_android_setup`	Quick setup: push CA cert + ADB reverse tunnel (no Wi-Fi proxy)

Caveats: CA cert injection requires root access. Supports Android 14+ (/apex/com.android.conscrypt/cacerts/). Wi-Fi proxy is opt-in (default off).

Android Frida (3)

Tool	Description
`interceptor_frida_apps`	List running apps on device via Frida
`interceptor_frida_attach`	Attach to app and inject SSL unpinning + proxy redirect scripts
`interceptor_frida_detach`	Detach Frida session from app

Caveats: Requires frida-server running on device. Uses frida-js (pure JS, no native binaries on host). SSL unpinning covers OkHttp, BoringSSL, TrustManager, system TLS — but may not work against QUIC or custom TLS stacks.

Docker (2)

Tool	Description
`interceptor_docker_attach`	Inject proxy env vars and CA cert into running container
`interceptor_docker_detach`	Remove proxy config from container

Two modes: exec (live injection, existing processes need restart) and restart (stop + restart container). Uses host.docker.internal for proxy URL.

Browser DevTools-equivalents (12)

Playwright-driven tools for the browser target. Each takes a target_id directly — no session binding, no sidecar. Works on both cloakbrowser (browser_* IDs) and camoufox (camoufox_* IDs) targets via the shared getPageForTarget() resolver.

Tool	Description
`interceptor_browser_snapshot`	ARIA/role YAML snapshot of the page (or selector subtree) — optimized for LLM page reasoning
`interceptor_browser_screenshot`	Screenshot. Writes to `file_path` if provided; otherwise reports byte count only
`interceptor_browser_list_console`	Buffered console messages since launch, with type/text filters and pagination
`interceptor_browser_list_cookies`	Cookie listing with filters, pagination, truncated value previews
`interceptor_browser_get_cookie`	Get one cookie by `cookie_id` (value is capped to keep output bounded)
`interceptor_browser_list_storage_keys`	localStorage/sessionStorage key listing with value previews
`interceptor_browser_get_storage_value`	Get one storage value by `item_id`
`interceptor_browser_list_network_fields`	Header field listing from proxy-captured traffic since the browser was launched
`interceptor_browser_get_network_field`	Get one full header field value by `field_id`
`interceptor_browser_evaluate`	Run a JS file in the page (file body wrapped as `(__args) => { ... }`); returns the result. `world: "isolated"` is the default. `world: "main"` is camoufox-only and requires `main_world_eval: true` at launch. On current camoufox build (cloverlabs/FF150) both permitted modes run in the page main world — mutations are page-visible
`interceptor_browser_inject_init_script`	Inject a JS file as `page.addInitScript` — runs before every page script on the next navigation. Cloakbrowser: isolated utility world. Camoufox (cloverlabs/FF150): page main world directly — patches reach the page but are observable by page scripts (`Function.prototype.toString` leak applies)
`interceptor_browser_add_script_tag`	Append a `<script>` to the current page. DOM-visible — avoid for stealth. Use for benign payloads where main-world execution + page visibility is intentional

Network data is sourced from the MITM proxy rather than a browser-side protocol — the proxy sees every wire request regardless of what the browser reported.

Stealth tradeoffs for JS injection:

Method	Cloakbrowser	Camoufox (cloverlabs/FF150)
`evaluate` isolated	Safe (isolated utility world) — rate-limit before reCAPTCHA, each call is CDP traffic	Runs in page main world; reads are invisible, mutations are page-observable
`evaluate` main	Not supported by Playwright API	Requires `main_world_eval: true` at launch; same realm as `isolated` on this build once enabled (`mw:` prefix does not create a distinct realm)
`inject_init_script`	Best for stealth — pre-document, no DOM artifact	Patches reach the page (good) but are observable via `Function.prototype.toString` and `window` enumeration; not stealth-safe for high-tier WAFs
`add_script_tag`	Detectable (DOM node, MutationObserver, CSP)	Detectable (same)

References: Playwright evaluate, Playwright addInitScript, Camoufox stealth.

Worlds and isolation — what your JS can and can't see

The two backends ship different world models. Picking the wrong tool is the most common stealth footgun, so the boundary matters.

Cloakbrowser (Chromium). Playwright's evaluate runs in an isolated "utility" world that shares globals with the page's main world. An addInitScript patch to navigator.webdriver is visible to (a) your subsequent evaluate probes AND (b) anti-bot code the site loads. This is the model most "stealth playbooks" assume. Detection vectors are CDP-side (Runtime.evaluate chatter) — cloakbrowser's C++ patches mitigate those.

Camoufox (cloverlabs ≥0.6 + Firefox 150 — current build). No separate JS world. page.evaluate and page.addInitScript both run in the page's main world, the same realm as a real <script> tag. Implications:

inject_init_script patches reach the page (e.g. Object.defineProperty(navigator, 'webdriver', ...) does affect what site scripts see). The DOWNSIDE: the patch is observable to anti-bot code on the page — Function.prototype.toString.toString() reveals replaced functions, Object.defineProperty hooks see the call.
interceptor_browser_evaluate reads are invisible (no window writes, no prototype changes). Mutating evals (() => { window.x = 1 }) are observable.
world: "isolated" and world: "main" accept the same script args for API compatibility but run in the same realm once main is enabled. main_world_eval: true still gates explicit world: "main" calls in proxy-mcp; on this build it does not create a separate execution realm.

Verify behavior on your installed build:

npx tsx scripts/camoufox-world-probe.ts --venv=/path/to/camoufox-venv

Historical note. Earlier daijro/camoufox (Firefox 135 line) ran evaluate and addInitScript in a separate Juggler scope that was invisible to the page — patches there did NOT reach site scripts (camoufox#48), but automation JS was equally invisible to anti-bot code. Cloverlabs/FF150 dropped that isolation. If your workflow depends on Juggler-scope invisibility, stay on daijro/FF135.

Practical rules:

Use case	Cloakbrowser	Camoufox (cloverlabs/FF150)
Read DOM / extract data	`interceptor_browser_evaluate` (isolated)	`interceptor_browser_evaluate` — reads don't leak
Modify page state, click via JS	`interceptor_browser_evaluate` (isolated; globals are shared)	`interceptor_browser_evaluate` — mutations are page-visible; use sparingly on stealth-sensitive targets
Spoof navigator / window fingerprints	`interceptor_browser_inject_init_script`	Configure at launch (`os`, `fonts`, `webgl_config`, `humanize`, `firefox_user_prefs`). Source-level patches are invisible. `inject_init_script` works but its patches are observable.
Load a 3rd-party JS lib into the page	`interceptor_browser_add_script_tag` (page sees it — usually OK if intentional)	Same — runs in main world; DOM node is detectable

Stealth note: on the current camoufox build, every JS-level mutation from automation is observable by anti-bot code on the page. Prefer source-level configuration over runtime patching. Use evaluate for reads, not writes, when stealth matters.

Sessions (14)

Persistent, queryable on-disk capture for long runs and post-crash analysis.

Tool	Description
`proxy_session_start`	Start persistent session capture (preview or full-body mode)
`proxy_session_stop`	Stop and finalize the active persistent session
`proxy_session_status`	Runtime status for persistence (active session, bytes, disk cap errors)
`proxy_import_har`	Import a HAR file from disk into a new persisted session
`proxy_list_sessions`	List recorded sessions from disk
`proxy_get_session`	Get manifest/details for one session
`proxy_query_session`	Indexed query over recorded exchanges
`proxy_search_session_bodies`	Search request/response bodies stored in a persistent session, with context snippets
`proxy_get_session_handshakes`	Report JA3/JA4/JA3S handshake metadata availability for session entries
`proxy_get_session_exchange`	Fetch one exchange from a session (with optional full bodies)
`proxy_replay_session`	Dry-run or execute replay of selected session requests
`proxy_export_har`	Export full session or filtered subset to HAR
`proxy_delete_session`	Delete a stored session
`proxy_session_recover`	Rebuild indexes from records after unclean shutdown

proxy_get_session_exchange and proxy_export_har automatically decompress response bodies (gzip, deflate, brotli) based on the stored content-encoding header. The returned responseBodyText and responseBodyBase64 contain the decompressed content. Raw compressed bytes are preserved on disk for exact replay fidelity.

Note on proxy_start with persistence_enabled: true: this auto-creates a session. A subsequent proxy_session_start() call returns the existing active session instead of failing — no need to stop and re-start.

Humanizer — Playwright Input (5)

Human-like browser input via Playwright page.mouse / page.keyboard. Works with browser_* targets from interceptor_browser_launch and camoufox_* targets from interceptor_camoufox_launch. Cloakbrowser's own humanize patches apply when enabled at launch; Camoufox cursor humanization follows the Camoufox launch config.

Tool	Description
`humanizer_move`	Move the mouse to `x,y` through the backend Playwright page
`humanizer_click`	Click a locator (`selector` / `role` + `name` / `text` / `label`) or raw `x,y`. Auto-waits for visible + enabled + stable + in-view before clicking
`humanizer_type`	Type text into the focused element via `page.keyboard.type`; optional `delay_ms` passes through to Playwright
`humanizer_scroll`	Dispatch one Playwright `page.mouse.wheel` event
`humanizer_idle`	Simulate idle behavior with mouse micro-jitter and occasional micro-scrolls to defeat idle detection

All tools require target_id from a prior interceptor_browser_launch or interceptor_camoufox_launch. The engine maintains tracked mouse position across calls for coordinate-based move/click/idle behavior.

Behavioral details:

Mouse: humanizer_move calls page.mouse.move; locator clicks call Playwright locators and raw-coordinate clicks call page.mouse.click
Typing: humanizer_type calls page.keyboard.type(text, { delay }) when delay_ms is provided; no WPM, typo, or bigram model is implemented in proxy-mcp
Scrolling: humanizer_scroll sends one wheel event with the requested delta
Idle: Periodic micro-jitter (±3px subtle / ±8px normal) and random micro-scrolls at configurable intensity

Resources

URI	Description
`proxy://status`	Proxy running state and config
`proxy://ca-cert`	CA certificate PEM
`proxy://traffic/summary`	Traffic stats: method/status breakdown, top hostnames, TLS fingerprint stats
`proxy://interceptors`	All interceptor metadata and activation status
`proxy://sessions`	Persistent session catalog + runtime persistence status
`proxy://browser/primary`	Current page URL/title for the most recently launched browser instance
`proxy://browser/targets`	Current page state for all active browser instances
`proxy://camoufox/targets`	Active camoufox instances with their wsUrl and fingerprint details
`proxy://sessions/{session_id}/summary`	Aggregate stats for one recorded session (resource template)
`proxy://sessions/{session_id}/timeline`	Time-bucketed request/error timeline (resource template)
`proxy://sessions/{session_id}/findings`	Top errors/slow exchanges/host error rates (resource template)

Usage Example

# Start the proxy
proxy_start

# Optional: start persistent session recording
proxy_session_start --capture_profile full --session_name "reverse-run-1"

# Configure device to use proxy (Wi-Fi settings or interceptors)
# Install CA cert on device (proxy_get_ca_cert)

# Or use interceptors to auto-configure targets:
interceptor_browser_launch                    # Launch stealth browser with proxy
interceptor_spawn --command curl --args '["https://example.com"]'  # Spawn proxied process
interceptor_android_activate --serial DEVICE_SERIAL               # Android device

# Set upstream proxy for geolocation
proxy_set_upstream --proxy_url socks5://user:pass@geo-proxy:1080

# Mock an API response
proxy_mock_response --url_pattern "/api/v1/config" --status 200 --body '{"feature": true}'

# Inject auth headers (set value to null to delete a header)
proxy_inject_headers --hostname "api.example.com" --headers '{"Authorization": "Bearer token123"}'

# View captured traffic
proxy_list_traffic --hostname_filter "api.example.com"
proxy_search_traffic --query "error"

# TLS fingerprinting
proxy_list_tls_fingerprints                # See unique JA3/JA4 fingerprints
proxy_set_ja3_spoof --ja3 "771,4865-..."   # Spoof outgoing JA3 (for non-browser clients)
proxy_set_fingerprint_spoof --preset chrome_136 --host_patterns '["example.com"]'  # Full fingerprint spoof
proxy_list_fingerprint_presets                  # Available browser presets

# Human-like browser interaction (browser_* or camoufox_* target)
humanizer_move   --target_id "browser_<id>" --x 500 --y 300
humanizer_click  --target_id "browser_<id>" --selector "#login-button"
humanizer_click  --target_id "browser_<id>" --role "button" --name "Sign in"
humanizer_type   --target_id "browser_<id>" --text "user@example.com" --delay_ms 45
humanizer_scroll --target_id "browser_<id>" --delta_y 300
humanizer_idle   --target_id "browser_<id>" --duration_ms 2000 --intensity subtle

# Run / inject JS in the page (cloakbrowser + camoufox)
interceptor_browser_evaluate           --target_id "browser_<id>" --script_path /tmp/probe.js
interceptor_browser_evaluate           --target_id "camoufox_<id>" --script_path /tmp/probe.js --world main   # camoufox + main_world_eval=true
interceptor_browser_inject_init_script --target_id "browser_<id>" --script_path /tmp/hook.js   # applies on next navigation
interceptor_browser_add_script_tag     --target_id "browser_<id>" --script_path /tmp/lib.js    # DOM-visible — avoid for stealth

# Query/export recorded session
proxy_list_sessions
proxy_query_session --session_id SESSION_ID --hostname_contains "api.example.com"
proxy_export_har --session_id SESSION_ID

Architecture

State: ProxyManager singleton manages mockttp server, rules, traffic
Rule rebuild: Rules must be set before mockttp start(), so rule changes trigger stop/recreate/restart cycle
Traffic capture: on('request') + on('response') events, correlated by request ID
Ring buffer: 1000 entries max, body previews capped at 4KB
TLS capture: Client JA3/JA4 from mockttp socket metadata; server JA3S via tls.connect monkey-patch
TLS spoofing: impit (native Rust TLS/HTTP2 impersonation via rustls); in-process, no container needed
Interceptors: Managed by InterceptorManager, each type registers independently
Browser: cloakbrowser (stealth Chromium, ~200 MB binary auto-downloaded on first launch) and Camoufox (anti-detect Firefox, installed separately) driven via Playwright BrowserContext / Page
Humanizer: Singleton engine using Playwright's page.mouse / page.keyboard, plus local mouse-position tracking for idle jitter

Testing

npm test              # All tests (unit + integration)
npm run test:unit     # Unit tests only
npm run test:integration  # Integration tests
npm run test:e2e      # E2E fingerprint tests (requires cloakbrowser + internet)

Credits

Core Libraries

Project	Role
mockttp	MITM proxy engine, rule system, CA generation
impit	Native TLS/HTTP2 fingerprint impersonation (Rust via NAPI-RS)
frida-js	Pure-JS Frida client for Android instrumentation
cloakbrowser	Stealth-patched Chromium with source-level C++ fingerprint patches
Camoufox	Anti-detect Firefox backend with source-level fingerprint controls
playwright-core	Browser automation API driving cloakbrowser and Camoufox
@modelcontextprotocol/sdk	MCP server framework

Vendored Frida Scripts

All scripts in src/frida-scripts/vendor/ are derived from httptoolkit/frida-interception-and-unpinning (MIT):

config-template.js — proxy/cert config injection
android-certificate-unpinning.js — TrustManager + OkHttp + BoringSSL hooks
android-system-certificate-injection.js — runtime cert injection via KeyStore
android-proxy-override.js — ProxySelector monkey-patch
native-tls-hook.js — BoringSSL/OpenSSL native hooks
native-connect-hook.js — libc connect() redirect

Available Tools

89 tools

humanizer_clickA

Click an element. Pass one of: selector (CSS/XPath), role + optional name, text, label, or raw x+y coords as fallback. Locator-based calls auto-wait for visible.

ParametersJSON Schema

Name	Required	Description	Default
`x`	No	X coordinate fallback when no locator is given
`y`	No	Y coordinate fallback when no locator is given
`name`	No	Accessible name; used with role (e.g. 'Sign in')
`role`	No	ARIA role (e.g. 'button', 'link', 'textbox')
`text`	No	Visible text to match (e.g. 'Accept cookies')
`label`	No	Form-field label text (e.g. 'Email address')
`button`	No	Mouse button (default: left)	left
`selector`	No	CSS or XPath selector (e.g. 'button.submit', '//button[@id="go"]')
`target_id`	Yes	Target ID from interceptor_browser_launch or interceptor_camoufox_launch
`timeout_ms`	No	Max ms to wait for locator to be visible + actionable (default: 15000)
`click_count`	No	Number of clicks (default: 1, use 2 for double-click)

TDQS

A4.4/5.0

Behavior4/5

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

The description discloses key behavioral traits: 'Locator-based calls auto-wait for visible' and the fallback nature of coordinates. With no annotations provided, the description carries the full burden and does so effectively, though it could mention what happens on failure or if multiple locators are provided.

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 extremely concise: two sentences with no unnecessary words. It front-loads the core action ('Click an element') and efficiently conveys parameter groupings and fallback behavior.

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

Completeness4/5

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

Given the complexity of 11 parameters and no output schema, the description is reasonably complete. It covers the core mechanic, parameter groupings, and auto-wait. It could be improved by noting error handling or return behavior, but the existing content is sufficient for an agent to use the tool correctly.

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

Parameters4/5

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

The description adds value beyond the input schema by grouping parameters ('Pass one of: selector, role+name, text, label, or raw x+y coords') and explaining mutual exclusivity. It also clarifies the auto-wait behavior tied to locator-based parameters. Since schema coverage is 100%, the baseline is 3, but the description provides additional structural context.

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 clearly states the tool's purpose: 'Click an element.' It lists multiple ways to specify the target (selector, role+name, text, label, coordinates), leaving no ambiguity about what the tool does. It is distinct from sibling tools like humanizer_move or humanizer_scroll.

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

Usage Guidelines4/5

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

The description explicitly instructs to 'Pass one of' the locator options, making it clear which parameters to use. It also mentions the auto-wait behavior for locator-based calls. However, it does not explicitly state when not to use this tool or provide alternatives for non-click actions, though the tool's name and purpose make this obvious.

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

humanizer_idleA

Simulate idle behavior with mouse micro-jitter and occasional micro-scrolls. Keeps the page 'alive' to avoid idle detection by bot-detection scripts.

ParametersJSON Schema

Name	Required	Description	Default
`intensity`	No	Idle intensity: 'subtle' (±3px jitter) or 'normal' (±8px jitter, more scrolls)	subtle
`target_id`	Yes	Target ID from interceptor_browser_launch or interceptor_camoufox_launch
`duration_ms`	Yes	How long to simulate idle behavior in ms

TDQS

A4/5.0

Behavior4/5

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

No annotations are provided, so the description carries full burden. It discloses the simulated idle behavior and its purpose (avoiding bot detection), but lacks details on any side effects or required permissions. Overall adequate for a non-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.

Conciseness5/5

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

Two sentences, efficiently conveying purpose and effect with no wasted words. Front-loaded with the main action.

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

Completeness4/5

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

For a simple tool with 3 parameters and no output schema, the description covers the core functionality and context (avoiding bot detection). It could be slightly more complete by clarifying edge cases or when not to use it, but it is sufficient for an agent to understand its role among sibling tools.

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

Parameters3/5

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

Schema coverage is 100%, so the description does not need to add much. The description itself does not elaborate on parameters, but the schema already provides clear descriptions for target_id, duration_ms, and intensity. Baseline score of 3 is appropriate.

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 clearly states the tool simulates idle behavior with mouse micro-jitter and micro-scrolls, which is a specific verb-resource pair and distinguishes it from active humanizer tools like click, move, etc.

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

Usage Guidelines3/5

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

The description implies usage for avoiding idle detection but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives.

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

humanizer_moveB

Move mouse to target coordinates via the backend Playwright page.

ParametersJSON Schema

Name	Required	Description
`x`	Yes	Destination X coordinate
`y`	Yes	Destination Y coordinate
`target_id`	Yes	Target ID from interceptor_browser_launch or interceptor_camoufox_launch

TDQS

B3.1/5.0

Behavior2/5

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 only states the action without disclosing behavioral traits such as whether the move is instant, triggers events, or waits for page load.

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

Conciseness4/5

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

A single, clear sentence with no fluff. Front-loaded with the essential action. Could include more detail without losing conciseness, but as is, it is efficient.

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

Completeness2/5

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

No output schema, and the description omits return values (e.g., success/failure). It does not mention whether movement is animated or instantaneous. For a simple action, more context is needed.

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

Parameters3/5

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

Schema coverage is 100% with descriptions for target_id, x, and y. The description adds no extra meaning beyond 'target coordinates', so it meets the baseline without enrichment.

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 clearly states the verb 'Move mouse', the resource 'target coordinates', and the method 'via the backend Playwright page'. It distinguishes this tool from siblings like humanizer_click or humanizer_scroll.

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?

No guidance on when to use this tool versus alternatives like humanizer_click or humanizer_scroll. It is implied that this is for cursor positioning, but there is no explicit context or exclusions.

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

humanizer_scrollA

Dispatch a wheel event. Raw page.mouse.wheel — single event, not multi-step.

ParametersJSON Schema

Name	Required	Description
`delta_x`	No	Horizontal scroll delta in pixels (default: 0)
`delta_y`	Yes	Vertical scroll delta in pixels (positive = scroll down)
`target_id`	Yes	Target ID from interceptor_browser_launch or interceptor_camoufox_launch

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses the tool dispatches a single raw wheel event, which is a basic behavioral trait. However, it lacks details on side effects, safety, or permissions beyond the event itself.

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?

Two short, focused sentences. The first states the purpose, the second adds precision with technical detail. No redundant or extraneous information.

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?

The tool is simple and the schema is complete, but the description does not differentiate it from sibling humanizer tools beyond stating it's a wheel event. It lacks context about when to use this tool over others like humanizer_click or humanizer_move.

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

Parameters3/5

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

Schema coverage is 100%, and the description adds no extra meaning to the parameters (target_id, delta_y, delta_x) beyond what the schema already provides. Baseline score of 3 is appropriate.

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 clearly states it dispatches a wheel event, specifying it is a single event using raw page.mouse.wheel. This distinguishes it from potential multi-step scrolling tools among siblings.

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

Usage Guidelines4/5

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

The description notes 'single event, not multi-step,' which implies when to use this tool (single scroll) and hints at when not to (multi-step scenarios). However, it does not explicitly mention alternative tools or conditions for avoiding this tool.

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

humanizer_typeA

Type text into the focused element via page.keyboard.type.

ParametersJSON Schema

Name	Required	Description
`text`	Yes	Text to type
`delay_ms`	No	Optional Playwright delay per character in ms.
`target_id`	Yes	Target ID from interceptor_browser_launch or interceptor_camoufox_launch

TDQS

A3.5/5.0

Behavior3/5

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

Without annotations, the description carries the burden. It reveals the mechanism (page.keyboard.type) but does not disclose side effects, limitations (e.g., special characters), or requirements (e.g., element must be focusable). It is minimally adequate.

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 a single, concise sentence that immediately states the action and method. No unnecessary words or redundancies.

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?

Given the tool's simplicity (3 parameters, no output schema), the description is functional but lacks details on behavior in edge cases (e.g., unfocused element). It is adequate but not comprehensive.

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

Parameters3/5

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

Schema coverage is 100% with clear parameter descriptions. The tool description adds no additional semantic value beyond what the schema already provides. Baseline score of 3 is appropriate.

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 clearly states that the tool types text into the focused element, specifying the underlying method (page.keyboard.type). It distinguishes itself from sibling tools like humanizer_click, humanizer_move, etc., which perform different actions.

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?

The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites (e.g., a focused element, a launched browser). It lacks explicit usage context.

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

interceptor_android_activateA

Full Android interception: inject CA cert into system store (root required), set up ADB reverse tunnel, and optionally set Wi-Fi proxy. Proxy must be running.

ParametersJSON Schema

Name	Required	Description
`serial`	Yes	ADB device serial (from interceptor_android_devices)
`inject_cert`	No	Push CA cert to system store (requires root)
`setup_tunnel`	No	Set up ADB reverse tunnel
`set_wifi_proxy`	No	Set global Wi-Fi HTTP proxy via adb settings

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description partially covers behavior (requires root, sets up tunnel, optionally proxy). However, it omits details on failure modes, side effects (e.g., system modification), and prerequisites like device connectivity.

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 a single, dense sentence that conveys all key actions and a prerequisite. Every word adds value, with no redundancy.

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?

Given the tool's complexity (4 parameters, no output schema), the description covers the core purpose and one prerequisite. It lacks mention of required serial, return value, or error handling, making it sufficient but not comprehensive.

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

Parameters3/5

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

The schema already provides 100% coverage with descriptions for each parameter. The description adds a high-level grouping but no additional meaning beyond what the schema offers.

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 clearly defines the tool's action: 'Full Android interception' with specific steps (inject CA cert, set up ADB reverse tunnel, optionally set Wi-Fi proxy). This distinguishes it from siblings like interceptor_android_deactivate and interceptor_android_setup.

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

Usage Guidelines3/5

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

The description states a prerequisite ('Proxy must be running') but does not explain when to use this tool versus alternatives, such as interceptor_android_setup. It lacks explicit context for when activation is appropriate.

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

interceptor_android_deactivateA

Remove ADB reverse tunnel and clear Wi-Fi proxy on an Android device.

ParametersJSON Schema

Name	Required	Description	Default
`target_id`	Yes	Target ID from interceptor_android_activate

TDQS

A3.8/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It states the actions but does not disclose potential side effects, required device state, or safety considerations for this destructive operation.

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 one sentence of 12 words, front-loaded with the verb, and contains no unnecessary information.

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

Completeness4/5

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

For a simple tool with one parameter and no output schema, the description adequately explains the tool's functionality. However, it could mention post-condition (e.g., device returns to normal state).

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

Parameters4/5

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

Schema coverage is 100% for the single parameter. The description adds context by specifying that the target_id comes from interceptor_android_activate, which helps the agent understand its origin.

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 uses specific verbs 'Remove' and 'clear' with resources 'ADB reverse tunnel' and 'Wi-Fi proxy'. It clearly distinguishes from sibling 'interceptor_android_activate' which does the opposite.

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

Usage Guidelines3/5

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

The description implies the tool is the inverse of activation but provides no explicit guidance on when to use it or alternatives. No exclusions 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.

interceptor_android_devicesA

List connected Android devices via ADB with model, version, root status, and whether they're actively intercepted.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It states what is listed, but does not disclose caching, refresh behavior, error scenarios (e.g., no devices), or state dependencies (e.g., active interception setup). Adequate but missing some context.

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?

Single sentence, front-loaded with action and resource, efficiently enumerates output fields with no redundancy. Every word earns its place.

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

Completeness4/5

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

For a no-parameter list tool without output schema, the description covers the necessary output fields. It lacks mention of empty result behavior or dependency on ADB, but overall sufficient given tool simplicity.

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

Parameters4/5

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

The input schema has zero parameters, so the description cannot add parameter meaning. Per guidelines, 0 params yields a baseline of 4. No further addition needed.

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 clearly specifies the action (List), the resource (connected Android devices via ADB), and the output fields (model, version, root status, interception status). This distinguishes it from siblings like interceptor_android_activate and interceptor_list.

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?

The description provides no guidance on when to use this tool versus alternatives, no prerequisites (e.g., ADB setup), and no exclusions. It does not help the agent decide between this and similar listing tools like interceptor_list.

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

interceptor_android_setupA

Quick setup: push CA cert + ADB reverse tunnel only (no Wi-Fi proxy). Equivalent to interceptor_android_activate with set_wifi_proxy=false.

ParametersJSON Schema

Name	Required	Description	Default
`serial`	Yes	ADB device serial

TDQS

A4.3/5.0

Behavior4/5

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

Despite no annotations, the description discloses the core operations (push CA cert, ADB reverse tunnel). It does not cover side effects or prerequisites, but for a one-param tool, the key behavior is adequately described.

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 extremely concise: two short sentences that front-load the purpose and include a comparison. Every sentence adds value without any unnecessary words.

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

Completeness5/5

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

For a simple setup tool with one required parameter and no output schema, the description provides sufficient context. It explains the tool's scope, its relationship to the sibling tool, and the key difference (no Wi-Fi proxy).

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

Parameters3/5

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

Schema coverage is 100% with the single parameter 'serial' having a description 'ADB device serial'. The tool description does not add any additional meaning beyond what the schema provides, so the baseline of 3 applies.

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 clearly states the tool's action: 'push CA cert + ADB reverse tunnel only (no Wi-Fi proxy)'. It also explicitly distinguishes it from sibling tool interceptor_android_activate by stating it's equivalent to that tool with set_wifi_proxy=false.

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

Usage Guidelines4/5

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

The description provides a direct usage hint: it's a 'Quick setup' for when Wi-Fi proxy is not needed. It references the alternative tool for the full setup, giving clear guidance on when to use this tool versus interceptor_android_activate.

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

interceptor_browser_add_script_tagA

Append a element to the current page (Playwright page.addScriptTag). WARNING: injects a real DOM node visible to MutationObserver, document.scripts, and CSP. Avoid for anti-bot stealth — prefer interceptor_browser_inject_init_script (no DOM node) when you need page-scope execution.

ParametersJSON Schema

Name	Required	Description	Default
`target_id`	Yes	Target ID from interceptor_browser_launch or interceptor_camoufox_launch
`script_path`	Yes	Absolute path to a .js file to inject as <script>.
`script_type`	No	`classic` (default) or `module`.	classic

TDQS

A4.5/5.0

Behavior4/5

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

Without annotations, the description discloses important behavioral traits: the injected script tag is a real DOM node visible to MutationObserver, document.scripts, and CSP, and warns about anti-bot stealth implications. It does not mention return values or error handling, but the core behavioral impact is covered.

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?

Two sentences: the first states the action and Playwright method, the second warns and directs to an alternative. No wasted words, front-loaded with core information.

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

Completeness5/5

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

For a simple 3-parameter tool with no output schema, the description covers purpose, behavioral impact, alternatives, and parameter context (script path and type). It is complete enough for an agent to correctly select and invoke this tool.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides (e.g., script_path is described as 'Absolute path to a .js file' in both).

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 explicitly states 'Append a <script> element to the current page' using Playwright's addScriptTag, and contrasts with the sibling tool interceptor_browser_inject_init_script, making the purpose clear and distinct.

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

Usage Guidelines5/5

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

The description provides explicit guidance on when to use this tool (when a visible DOM script tag is acceptable) and when to avoid it (for anti-bot stealth), and names the alternative tool to use instead (interceptor_browser_inject_init_script).

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

interceptor_browser_closeA

Close a browser instance launched by interceptor_browser_launch (or interceptor_camoufox_launch).

ParametersJSON Schema

Name	Required	Description	Default
`target_id`	Yes	Target ID from interceptor_browser_launch or interceptor_camoufox_launch

TDQS

A3.7/5.0

Behavior3/5

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

No annotations provided, so description must cover behavior. It conveys closure action but does not detail side effects (e.g., termination, state loss). Basic but adequate.

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

Conciseness4/5

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

Efficient single sentence with no wasted words. Could be slightly expanded for context, but remains concise and front-loaded.

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

Completeness4/5

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

For a simple close operation, description is adequate: action, resource, parameter source. Lacks error handling info but matches low complexity.

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

Parameters3/5

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

Schema already fully describes the parameter with 100% coverage. Description reinforces the source of target_id but adds limited value beyond schema.

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?

Description clearly states the action (close) and resource (browser instance), and specifies the launching tools, distinguishing it from siblings like interceptor_browser_launch.

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

Usage Guidelines3/5

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

Implicitly indicates usage after launching a browser, but lacks explicit guidance on when not to use or alternatives (e.g., interceptor_camoufox_close).

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

interceptor_browser_evaluateA

Execute a JS file in the page and return its result. Source is loaded from script_path (absolute path). The file body is wrapped in an arrow function receiving __args (so the file may return value; directly and access the optional args object). Worlds: isolated (default) or main (camoufox-only, requires main_world_eval: true at launch). Cloakbrowser (Chromium): isolated runs in Playwright's utility world (different window, same DOM). main is rejected — use interceptor_browser_inject_init_script for main-world patching there. Camoufox (cloverlabs/FF150): there is no separate isolated world — both permitted modes run in the page's main world. Reads are invisible to the page; mutations (window.x = …, Object.defineProperty, prototype patches) are observable by page scripts. Earlier daijro/FF135 had a Juggler scope that made isolated invisible to the page; that scope was removed in cloverlabs. Verify on your installed build with scripts/camoufox-world-probe.ts. Rate-limit on cloakbrowser before reCAPTCHA: each call emits CDP traffic that behavioural scorers count.

ParametersJSON Schema

Name	Required	Description	Default
`args`	No	Optional JSON-serialisable args object, available inside the script as `__args`.
`world`	No	`isolated` (default) or `main`. On current camoufox build (cloverlabs/FF150) both run in the page's main world — arg is accepted but has no observable effect.	isolated
`target_id`	Yes	Target ID from interceptor_browser_launch or interceptor_camoufox_launch
`script_path`	Yes	Absolute path to a .js file. File body is the function body; use `return` to send a value back.
`value_max_chars`	No	Max characters of the JSON-stringified return value (default: 20000).

TDQS

A4.7/5.0

Behavior5/5

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

Discloses multiple behavioral traits: script wrapping in arrow function, world isolation differences, mutation visibility, rate-limiting implications, and provides a verification command. No annotations present, so description fully covers the burden.

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

Conciseness4/5

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

Description is detailed and front-loaded with the main purpose, but slightly verbose. Could be trimmed while retaining key information, but still well-structured and informative.

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

Completeness4/5

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

Covers environment differences, safety, limitations, and return value truncation. Lacks explicit return value format but infers JSON-stringified result. Adequate for a complex tool with no output schema.

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

Parameters4/5

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

Schema has 100% coverage, so baseline is 3. Description adds value by explaining that script_path is absolute, args accessible as __args, world mode details, and default for value_max_chars.

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?

Description clearly states 'Execute a JS file in the page and return its result' with a specific verb and resource. It distinguishes from sibling tools like interceptor_browser_inject_init_script by explaining when to use each.

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

Usage Guidelines5/5

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

Provides explicit guidance on when to use isolated vs main world, including platform-specific behavior (Cloakbrowser vs Camoufox) and suggests alternative tool for main-world patching on Chromium.

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

interceptor_browser_get_cookieA

Get one cookie by cookie_id with full value (subject to a hard cap to keep output bounded).

ParametersJSON Schema

Name	Required	Description
`cookie_id`	Yes	cookie_id from interceptor_browser_list_cookies
`target_id`	Yes	Target ID from interceptor_browser_launch or interceptor_camoufox_launch
`value_max_chars`	No	Max characters for cookie value (default: 20000)

TDQS

A3.8/5.0

Behavior3/5

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

The description notes a 'hard cap to keep output bounded', which signals potential truncation, but lacks details on side effects, authentication needs, or error handling. Since no annotations are provided, the description should carry more 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.

Conciseness5/5

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

The description is a single, front-loaded sentence with a parenthetical qualifier. It is concise and contains no superfluous information.

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

Completeness4/5

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

Given the tool has 3 parameters, no output schema, and no annotations, the description covers the core purpose and a key behavioral constraint. It could mention what happens if the cookie_id is invalid or the cap is exceeded, but overall it is sufficient for basic use.

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

Parameters3/5

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

All three parameters are fully described in the input schema (100% coverage). The description adds a general note about the hard cap but does not elaborate on parameter-specific semantics beyond the schema.

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 clearly states 'Get one cookie by cookie_id', specifying the verb (get) and resource (cookie), and adds a constraint about a hard cap. It distinguishes from sibling tools like interceptor_browser_list_cookies which returns multiple cookies.

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

Usage Guidelines3/5

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

The description implies use when a specific cookie's full value is needed, but it does not explicitly state when to use this tool versus alternatives (e.g., list_cookies for multiple, or get_storage_value for other storage). No when-not or alternatives are given.

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

interceptor_browser_get_network_fieldB

Get one full header field value from proxy-captured traffic by field_id.

ParametersJSON Schema

Name	Required	Description
`field_id`	Yes	field_id from interceptor_browser_list_network_fields
`target_id`	Yes	Target ID from interceptor_browser_launch or interceptor_camoufox_launch
`value_max_chars`	No	Max characters for returned value (default: 20000)

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits but only says 'get', implying a read operation. It fails to mention truncation behavior via value_max_chars, error handling, or the nature of the returned value. Minimal transparency.

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

Conciseness4/5

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

The description is a single, concise sentence with no wasted words. However, it is overly brief and misses opportunities to add value, preventing a perfect score.

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

Completeness2/5

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

The description is too minimal given the tool's complexity: 3 parameters, no output schema, and no annotations. It lacks details on return value, relation to sibling tools, and typical usage flow.

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

Parameters3/5

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

Schema coverage is 100%, so the input schema already explains all parameters. The description adds no additional meaning beyond what is in the schema, earning the baseline score of 3.

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?

Description clearly states the tool gets a full header field value from proxy-captured traffic using a field_id, distinguishing it from sibling tools like interceptor_browser_list_network_fields (which lists fields) and interceptor_browser_get_cookie (which gets cookies).

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?

No guidance on when to use this tool versus alternatives, no mention of prerequisite steps (e.g., obtaining field_id from list_network_fields), and no exclusions or context provided.

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

interceptor_browser_get_storage_valueB

Get one localStorage/sessionStorage value by item_id.

ParametersJSON Schema

Name	Required	Description
`origin`	No	Optional origin override (must match current page origin)
`item_id`	Yes	item_id from interceptor_browser_list_storage_keys
`target_id`	Yes	Target ID from interceptor_browser_launch or interceptor_camoufox_launch
`storage_type`	Yes	Storage type
`value_max_chars`	No	Max characters for returned value (default: 20000)

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description should disclose behavioral traits like non-destructiveness, side effects, or error handling. It only states the action, omitting whether the operation is read-only, what happens if the key is missing, or any 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.

Conciseness4/5

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

The description is concise with a single sentence, front-loading the verb and resource. However, it could be more structured by adding prerequisite context without becoming overly long.

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

Completeness2/5

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

Given 5 parameters, no output schema, and no annotations, the description is incomplete. It fails to explain optional fields like origin and value_max_chars, or how the tool integrates with sibling tools like browser navigation or snapshot.

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

Parameters3/5

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

Schema coverage is 100%, so baseline is 3. The description adds minimal meaning beyond the schema, as the key detail 'by item_id' is already present. No extra semantic value is provided.

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 clearly states the tool gets a value from localStorage or sessionStorage by item_id, using specific verbs and resources. It distinguishes from siblings that list keys or get cookies.

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?

No explicit when-to-use or when-not-to-use guidance is provided. It does not mention prerequisites like obtaining target_id from launch or item_id from list_storage_keys, nor does it specify alternatives.

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

interceptor_browser_inject_init_scriptA

Inject a JS file as an init script (Playwright page.addInitScript). Runs before any page script on every subsequent navigation/frame. Cloakbrowser (Chromium): runs in the isolated utility world — no DOM artifact; patches to shared prototypes/globals reach the page main world via utility-world sharing. Camoufox (cloverlabs/FF150): runs directly in the page's main world. Patches (e.g. Object.defineProperty(navigator, 'webdriver', ...)) DO apply to the page, but are observable by anti-bot code on the page (Function.prototype.toString leak applies). For Camoufox stealth, prefer source-level fingerprint config at launch (os, webgl_config, fonts, humanize, …) over JS injection. Earlier daijro/FF135 ran init scripts in a Juggler scope that did NOT reach the page (camoufox#48); cloverlabs/FF150 removed that scope. Does NOT affect the currently loaded document — navigate again to apply.

ParametersJSON Schema

Name	Required	Description	Default
`target_id`	Yes	Target ID from interceptor_browser_launch or interceptor_camoufox_launch
`script_path`	Yes	Absolute path to a .js file to inject before page scripts on every load.

TDQS

A4.7/5.0

Behavior5/5

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

No annotations provided, so the description fully carries the burden. It details execution contexts: for Chromium, runs in isolated utility world with shared prototypes; for Firefox, runs directly in page main world with observable patches (e.g., Function.prototype.toString leak). Also covers historical changes (FF135 vs FF150). Provides comprehensive behavioral disclosure.

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 concise yet thorough, front-loading the core purpose and then providing engine-specific details, caveats, and alternatives. Every sentence adds value without redundancy. Well-structured for quick comprehension.

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

Completeness5/5

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

Given no output schema and no annotations, the description covers all necessary contextual aspects: execution behavior on different engines, version differences, recommendation against use for certain cases, and the need for navigation to apply. An agent can fully understand when and how to use this tool.

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

Parameters3/5

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

Schema description coverage is 100% (both parameters documented). The description adds no additional meaning beyond what the schema already provides for the parameters. The behavioral context about injection timing and world scope is valuable but pertains to the tool's operation, not parameter semantics. Thus baseline 3 is appropriate.

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 clearly states the tool injects a JS file as an init script via Playwright's addInitScript, runs before any page script on every navigation/frame. It distinguishes between Cloakbrowser (Chromium) and Camoufox (Firefox) behaviors, and differentiates from sibling tools like interceptor_camoufox_launch or interceptor_browser_add_script_tag by specifying the execution context and when to prefer alternative approaches.

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

Usage Guidelines5/5

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

Explicitly advises when to use and when not: for Camoufox, suggests using source-level fingerprint config at launch over JS injection due to observability. Notes that init scripts do not affect the currently loaded document, requiring navigation to apply. Also mentions legacy behavior in daijro/FF135, guiding the agent away from this tool in that context.

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

interceptor_browser_launchA

Launch cloakbrowser (stealth Chromium) with proxy flags and SPKI certificate trust. Built-in source-level fingerprint patches + humanize mode. Driven via Playwright — locator-based tools replace CDP.

ParametersJSON Schema

Name	Required	Description	Default
`url`	No	URL to open (default: about:blank)
`locale`	No	BCP 47 locale, e.g. 'en-US'
`headless`	No	Run headless (default: false)
`humanize`	No	Enable cloakbrowser's humanize mode (default: true)
`timezone`	No	IANA timezone, e.g. 'America/New_York'
`human_preset`	No	Human behavior preset	default
`viewport_width`	No	Viewport width in px
`viewport_height`	No	Viewport height in px

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description carries the burden. It discloses behavioral aspects: launching with proxy and SPKI trust, source-level fingerprint patches, humanize mode, and Playwright driving. However, it lacks details on side effects, prerequisites (e.g., proxy setup), error conditions, or return value.

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 exceptionally concise: two sentences (40 words) with no filler. Every word adds value: first sentence states purpose and key features, second clarifies technical driver and subsequent tool usage. It is front-loaded and efficient.

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?

Given the lack of output schema and annotations, the description should cover return values and setup dependencies. It mentions Playwright and locator tools but does not specify what the tool returns (e.g., browser session ID) or prerequisites (e.g., proxy configuration). This is adequate but has clear gaps.

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

Parameters3/5

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

Input schema has 100% description coverage for all 8 parameters, each with defaults and one enum. The description does not add additional meaning beyond the schema, so the baseline score of 3 is appropriate.

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 clearly states the tool 'launch[es] cloakbrowser (stealth Chromium)' with specific features (proxy flags, SPKI trust, fingerprint patches, humanize mode). It differentiates from sibling tools like interceptor_camoufox_launch by specifying the browser type and mentioning Playwright-driven locator tools.

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

Usage Guidelines3/5

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

The description implies the tool is for launching a stealth browser for tasks requiring fingerprint protection and humanization, but it does not explicitly state when to use this tool versus alternatives (e.g., interceptor_camoufox_launch) or mention scenarios where it should not be used.

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

interceptor_browser_list_consoleA

List console messages buffered since the browser was launched. Types: log, info, warning, error, debug, etc.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max messages to return (default: 50, max: 500)
`types`	No	Filter by console message types
`offset`	No	Offset into results (default: 0)
`target_id`	Yes	Target ID from interceptor_browser_launch or interceptor_camoufox_launch
`text_filter`	No	Filter by text substring

TDQS

A3.7/5.0

Behavior3/5

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

The description discloses that messages are buffered since browser launch and mentions message types, which is useful. However, with no annotations, it lacks details on read-only nature, authorization requirements, or potential side effects like clearing buffers.

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 two sentences, no fluff. The first sentence states the core function, the second gives example types. Efficient and front-loaded.

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?

Given no output schema, the description could explain the output format or mention that filtering via parameters (types, text_filter) is supported. It covers the basic purpose but lacks optional completeness for a list tool with parameters.

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

Parameters3/5

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

The input schema has 100% description coverage for all 5 parameters. The description adds high-level context (buffer, types) but does not add per-parameter details beyond the schema. Baseline of 3 is appropriate.

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 clearly states the tool lists console messages buffered since launch and provides example types (log, info, warning, error, debug). It distinguishes itself from sibling tools like list_cookies or list_network_fields by focusing on console messages.

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

Usage Guidelines3/5

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

The description implies usage after launching a browser but does not explicitly state when to use this tool versus alternatives, such as other list tools or evaluating JS directly. No when-not-to-use guidance is provided.

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

interceptor_browser_list_cookiesA

List cookies from the browser context with pagination and truncated value previews.

ParametersJSON Schema

Name	Required	Description	Default
`full`	No	Return full cookie values instead of previews (capped at 20000 chars). Overrides value_max_chars.
`sort`	No	Sort order (default: name)	name
`limit`	No	Max cookies to return (default: 50, max: 500)
`offset`	No	Offset into results (default: 0)
`target_id`	Yes	Target ID from interceptor_browser_launch or interceptor_camoufox_launch
`url_filter`	No	Filter cookies by domain/path substring
`name_filter`	No	Filter cookies by name substring
`domain_filter`	No	Filter cookies by domain substring
`value_max_chars`	No	Max characters for cookie value previews (default: 256)

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, and the description lacks disclosure of behavioral traits such as read-only nature, side effects, or lifecycle requirements. It mentions pagination and previews but does not fully compensate for missing annotations.

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 a single sentence, front-loaded with purpose, and contains no unnecessary words.

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

Completeness4/5

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

Given the number of parameters and absence of output schema, the description covers the essential aspects (pagination, previews) and is comprehensive enough for the tool's purpose. It could mention return format, but not strictly required.

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

Parameters3/5

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

Schema coverage is 100%, and the schema descriptions are detailed. The description adds the concept of 'truncated value previews' but does not provide additional meaning beyond what the schema already conveys.

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 clearly states the verb (list), resource (cookies), and key features (pagination and truncated value previews). It distinguishes from sibling tool 'interceptor_browser_get_cookie' which is for a single cookie.

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

Usage Guidelines3/5

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 vs. alternatives, nor does it provide exclusions. The purpose is clear, but guidance on usage context is missing.

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

interceptor_browser_list_network_fieldsA

List request/response header fields from proxy-captured traffic since the browser was launched, with pagination and truncation.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Max fields to return (default: 50, max: 500)
`offset`	No	Offset into results (default: 0)
`direction`	No	Header direction (default: both)	both
`target_id`	Yes	Target ID from interceptor_browser_launch or interceptor_camoufox_launch
`url_filter`	No	Filter by URL substring
`method_filter`	No	Filter by HTTP method
`status_filter`	No	Filter by response status code
`hostname_filter`	No	Filter by hostname substring
`value_max_chars`	No	Max characters for header value previews (default: 256)
`header_name_filter`	No	Filter by header name substring

TDQS

A3.6/5.0

Behavior3/5

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

Annotations are not provided, so the description must disclose behavioral traits. It mentions pagination and truncation (offset, limit, value_max_chars) and implies read-only access, but does not explicitly state that no side effects occur or what happens when called without a browser (e.g., empty results). No contradictions with annotations.

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?

Single sentence that efficiently conveys purpose and key features (pagination, truncation). No redundant words or structural issues.

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

Completeness2/5

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

The tool has 10 parameters and no output schema. The description does not specify the format or content of the returned data (e.g., array of objects with fields like name, value, direction). This leaves the agent guessing about the return structure, making it incomplete for complex usage.

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

Parameters3/5

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

Schema description coverage is 100%, with each parameter already described. The description adds no additional meaning beyond the schema; it merely summarizes pagination/truncation. Baseline score of 3 is appropriate since schema does the heavy lifting.

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 clearly states the action (list) and resource (request/response header fields from proxy-captured traffic since browser launch). It also mentions pagination and truncation features, distinguishing it from sibling tools like proxy_list_traffic which lists full traffic entries.

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

Usage Guidelines3/5

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

The description implies usage context (after browser launch, from proxy-captured traffic) but does not explicitly state when to use this tool vs alternatives like proxy_get_exchange or proxy_search_traffic. No when-not or exclusion criteria are provided.

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

interceptor_browser_list_storage_keysA

List localStorage/sessionStorage keys for the current origin with pagination and truncated value previews.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max items to return (default: 50, max: 500)
`offset`	No	Offset into results (default: 0)
`origin`	No	Optional origin override (must match current page origin)
`target_id`	Yes	Target ID from interceptor_browser_launch or interceptor_camoufox_launch
`key_filter`	No	Filter by key substring
`storage_type`	Yes	Storage type
`value_max_chars`	No	Max characters for storage value previews (default: 256)

TDQS

A3.7/5.0

Behavior3/5

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

No annotations provided. The description mentions pagination and truncated value previews, but lacks details on side effects, permissions, or error states. It does not contradict annotations.

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?

A single, concise sentence (12 words) conveying all essential information with no redundancy.

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?

The description is adequate for a 7-parameter tool with no output schema, but lacks details on return format, behavior when no keys match, or how pagination is indicated. More context would improve completeness.

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

Parameters3/5

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

Schema coverage is 100% with detailed parameter descriptions. The tool description adds minimal value beyond 'pagination and truncated value previews', which is already implied by parameters like offset, limit, and value_max_chars.

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 clearly states it lists localStorage/sessionStorage keys for the current origin, with pagination and truncated value previews. It implicitly distinguishes from sibling 'interceptor_browser_get_storage_value' which gets a specific value.

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

Usage Guidelines3/5

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

The description gives no explicit guidance on when to use vs alternatives like 'interceptor_browser_get_storage_value' or when not to use. Usage is implied but not stated.

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

interceptor_browser_navigateA

Navigate the browser target's page via Playwright and optionally wait for matching host traffic to be captured by the proxy.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	Destination URL
`target_id`	Yes	Target ID from interceptor_browser_launch or interceptor_camoufox_launch
`timeout_ms`	No	Max wait for navigation and proxy capture (default: 5000ms)
`wait_until`	No	Playwright wait condition (default: domcontentloaded)	domcontentloaded
`poll_interval_ms`	No	Polling interval while waiting for proxy capture (default: 200ms)
`wait_for_proxy_capture`	No	Wait for matching proxy traffic after navigate (default: true)

TDQS

A3.5/5.0

Behavior3/5

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

The description mentions the optional proxy traffic waiting behavior, but does not disclose other potential side effects like page state changes, network activity, or error conditions. With no annotations, the description carries the full burden but provides only basic behavioral info.

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 a single sentence that is front-loaded and efficient. Every word contributes to the core purpose and optional behavior, with no redundancy.

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?

Despite having 6 parameters and no output schema, the description does not cover return values, failure scenarios, or usage context. It is minimally adequate but lacks completeness for a non-trivial tool.

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

Parameters3/5

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

All parameters have schema descriptions (100% coverage), so the description adds no new meaning beyond the schema. Baseline of 3 is appropriate.

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 clearly states it navigates a browser page via Playwright, using a specific verb and resource. It distinguishes itself from sibling tools like interceptor_browser_evaluate or interceptor_browser_screenshot, as navigation is a unique action.

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 on when to use this tool versus alternatives. No when-not-to-use or comparison to other tools is provided, leaving the agent without context for selection.

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

interceptor_browser_screenshotA

Take a screenshot of the bound page. Saves to file_path if provided; otherwise reports byte count without embedding the image.

ParametersJSON Schema

Name	Required	Description	Default
`format`	No	Image format (default: png)	png
`quality`	No	JPEG quality 0-100 (ignored for png)
`file_path`	No	Optional path to save screenshot
`full_page`	No	Capture the full scrollable page
`target_id`	Yes	Target ID from interceptor_browser_launch or interceptor_camoufox_launch

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: conditional saving to file_path and byte count reporting without embedding. This provides useful context beyond the input schema.

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 two sentences, front-loaded with the action, and every word contributes meaning. No unnecessary information.

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

Completeness5/5

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

Given the tool's simplicity, all five parameters are documented in the schema, and the description explains both output modes. No output schema is needed, and the description is adequate for an agent to select and invoke correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the behavior of file_path (save vs. report byte count), which is not fully captured by the schema alone.

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 clearly states the tool takes a screenshot of a bound page, specifying two modes (save to file or report byte count). It unambiguously identifies the resource and action, distinguishing it from sibling tools.

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

Usage Guidelines3/5

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

The description does not provide explicit guidance on when to use this tool versus alternatives or when not to use it. However, since there are no other screenshot tools among siblings, the implied usage is sufficient.

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

interceptor_browser_snapshotA

Take an ARIA accessibility snapshot of the bound page (YAML-formatted role tree). Great for LLM-driven page understanding without parsing HTML.

ParametersJSON Schema

Name	Required	Description	Default
`mode`	No	Snapshot mode — 'ai' adds ref attributes for locator reuse	default
`selector`	No	Root selector to snapshot (default: 'body')	body
`target_id`	Yes	Target ID from interceptor_browser_launch or interceptor_camoufox_launch

TDQS

A3.5/5.0

Behavior2/5

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

No annotations provided; description lacks disclosure of side effects, read-only nature, or permission requirements. Only states it's a snapshot, implying no modification but not explicit.

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?

Two succinct sentences, no filler. Front-loaded with action and output format.

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?

Covers basic purpose and output but lacks detail on return value structure, mode differences, and no behavioral notes. Adequate but leaves gaps for an agent to infer.

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

Parameters3/5

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

All parameters are documented in the schema (100% coverage), so description adds little value. It only hints at output format (YAML) but not parameter specifics beyond what schema already provides.

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?

Clear verb+resource: 'Take an ARIA accessibility snapshot'. YAML-format mention and 'without parsing HTML' distinguish from visual and evaluation tools.

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

Usage Guidelines3/5

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

Implied usage via 'Great for LLM-driven page understanding' but no explicit when-to-use or when-not-to-use compared to sibling tools like screenshot or evaluate.

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

interceptor_camoufox_closeA

Close a camoufox instance launched by interceptor_camoufox_launch. Kills the Python launcher, removes the temp launcher dir, and removes the NSS profile dir if one was created.

ParametersJSON Schema

Name	Required	Description	Default
`target_id`	Yes	Target ID from interceptor_camoufox_launch

TDQS

A4.2/5.0

Behavior4/5

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 discloses destructive actions (killing, removing directories), providing transparency beyond what a read-only annotation might. Missing details like error handling or idempotency are minor given the tool's simple cleanup role.

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?

A single sentence efficiently conveys the tool's purpose, actions, and input source. No superfluous information.

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

Completeness4/5

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

The description adequately covers the tool's behavior for a simple cleanup operation with one parameter. It lacks details about return values (no output schema) and handling of invalid inputs, but these are minor omissions.

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

Parameters3/5

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

Schema describes target_id fully (100% coverage). The description merely restates it as 'from interceptor_camoufox_launch', adding no new semantics beyond the schema. Baseline 3 is appropriate.

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 clearly states the tool closes a camoufox instance launched by interceptor_camoufox_launch, specifying actions like killing the launcher and removing directories. This distinctly sets it apart from sibling tools like interceptor_camoufox_launch, info, and list.

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

Usage Guidelines4/5

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

The description implies usage after a launch, with no explicit alternatives or when-not-to-use. However, the context of sibling tools (e.g., interceptor_browser_close) helps differentiate, making usage relatively clear.

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

interceptor_camoufox_infoA

Get the wsUrl and ready-to-paste Playwright connect snippets (TS + Python) for a camoufox target.

ParametersJSON Schema

Name	Required	Description	Default
`target_id`	Yes	Target ID from interceptor_camoufox_launch

TDQS

A4.1/5.0

Behavior4/5

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

No annotations are provided, so the description handles behavioral disclosure. It indicates a read-only operation (Get) and specifies the output (wsUrl and snippets), which is transparent enough for an info retrieval tool. However, it could mention that the target must be active.

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 a single sentence with only 16 words, front-loaded with the verb 'Get', and contains no extraneous information. Every word earns its place.

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

Completeness5/5

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

Given the tool's simplicity (1 required parameter, no output schema), the description adequately explains what the tool returns (wsUrl and snippets) and implies the precondition (target launched). Output specifics are sufficiently documented.

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

Parameters3/5

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

Schema coverage is 100% with the target_id parameter already described as 'Target ID from interceptor_camoufox_launch'. The description adds little beyond this, so baseline score of 3 applies.

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 clearly states it retrieves wsUrl and Playwright snippets for a camoufox target, using a specific verb and resource. It distinguishes itself from sibling tools like launch and list by focusing on info retrieval for an existing target.

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

Usage Guidelines3/5

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

The description implies usage after launching a target via interceptor_camoufox_launch, but does not explicitly state when to use this tool vs alternatives like list (which may also provide info) or provide any exclusions or prerequisites beyond the required target_id.

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

interceptor_camoufox_launchA

Launch camoufox (anti-detect Firefox) as a Playwright WebSocket server, proxied through proxy-mcp with NSS CA trust. Returns a camoufox target_id, wsUrl, and safe fingerprint introspection; drive the target with interceptor_browser_* and humanizer_* tools, or use wsUrl for custom Playwright code. Requires pip install cloverlabs-camoufox[geoip] + python3 -m camoufox fetch official/150.0.2-alpha.26 on the host (and libnss3-tools for cert trust).

ParametersJSON Schema

Name	Required	Description	Default
`os`	No	Fingerprint OS to emulate (default: host OS; pass an array to let Camoufox choose from those OS families)
`port`	No	Fixed WS server port (default: random)
`fonts`	No	Extra font families to inject (must be installed on the host)
`geoip`	No	true (auto-detect from proxy IP), false, or explicit IP string
`addons`	No	Paths to extracted Firefox addon directories
`config`	No	Raw camoufox config property overrides (advanced)
`locale`	No	BCP 47 locale or 2-letter country code
`ws_path`	No	Fixed WS URL path (default: random)
`headless`	No	true (default), false, or 'virtual' (Xvfb on Linux)
`humanize`	No	true = humanize cursor; number = max seconds for cursor humanization
`block_webgl`	No	Block WebGL entirely
`block_images`	No	Block image requests (saves proxy bandwidth)
`block_webrtc`	No	Block WebRTC to prevent IP leaks (default true)
`disable_coop`	No	Disable COOP — needed for Cloudflare Turnstile iframes
`enable_cache`	No	Cache pages/requests (disabled by default)
`webgl_config`	No	[vendor, renderer] WebGL pair (must be valid for the chosen OS)
`main_world_eval`	No	Allow explicit `world: 'main'` evaluate calls. On cloverlabs/FF150 this gates the call but does not create a separate realm.
`trust_proxy_cert`	No	Run certutil to inject the proxy CA into a fresh NSS profile (default true)
`python_executable`	No	Python executable for the launcher (e.g. 'uv run python3')	python3

TDQS

A4.1/5.0

Behavior4/5

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 clearly states the action (launch), the prerequisites, and the return values (target_id, wsUrl, fingerprint). It mentions the process type (WebSocket server) but does not detail side effects like concurrency limits or resource usage, which would improve transparency.

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

Conciseness4/5

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

The description is a single paragraph that front-loads the main action and then lists prerequisites and returns. It is reasonably concise but dense, combining multiple pieces of information without separation. It could be slightly more structured.

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

Completeness4/5

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

Given 19 parameters, no output schema, and no required params, the description is fairly complete. It explains the tool's purpose, prerequisites, and how to use the returned values with sibling tools. However, it does not provide examples or describe the exact structure of the return value.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description adds minimal value beyond the schema, providing only an overview. It does not elaborate on parameter interactions or provide additional context that is missing from the schema.

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 clearly states the verb 'Launch camoufox (anti-detect Firefox)' and identifies the resource as a Playwright WebSocket server with proxy and NSS CA trust. It distinguishes from sibling interceptor_browser_launch by specifying anti-detect Firefox and linking to related tools.

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

Usage Guidelines4/5

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

The description provides prerequisites (pip install, fetch, libnss3-tools) and suggests using interceptor_browser_* and humanizer_* tools to drive the target. It implicitly contrasts with interceptor_browser_launch but does not explicitly state when to avoid this tool or list alternatives.

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

interceptor_camoufox_listA

List all active camoufox instances with their wsUrl and fingerprint details.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It discloses the list of all active instances with specific details but does not mention potential side effects, authentication needs, or performance considerations. Basic transparency is adequate.

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?

One sentence of 10 words, no redundancy, perfectly concise while covering purpose and output details.

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

Completeness5/5

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

Given no parameters and no output schema, the description sufficiently explains the tool's function and return value. No missing information.

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

Parameters4/5

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

The tool has zero parameters, so the description does not need to clarify parameters. Baseline 4 applies as per guidelines.

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 clearly states the verb 'List', the resource 'active camoufox instances', and the specific output details ('wsUrl and fingerprint details'). It distinguishes itself from sibling tools like interceptor_list or interceptor_camoufox_info.

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?

No guidance on when to use this tool versus alternatives such as interceptor_camoufox_info or interceptor_list. The description only states what it does without providing context for selection.

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

interceptor_deactivate_allA

Kill ALL active interceptors across all types. Emergency cleanup — stops all browser instances, kills spawned processes, removes ADB tunnels, detaches Frida, cleans Docker.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations, the description fully discloses destructive side effects: stops browser instances, kills spawned processes, removes ADB tunnels, detaches Frida, cleans Docker. This is comprehensive and beyond minimal requirements.

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?

Extremely concise: one sentence with a clear action followed by a list of effects. Front-loaded with the core function. No wasted words.

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

Completeness5/5

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

For a parameterless tool with no output schema, the description covers all necessary context: purpose, scope, and specific effects. Nothing missing for effective agent invocation.

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?

Tool has zero parameters, baseline is 4. The description adds significant meaning by clarifying the scope ('ALL'). It effectively replaces any need for parameter documentation.

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 uses specific verb 'Kill' and resource 'ALL active interceptors across all types', and lists concrete actions (stops browsers, kills processes, removes ADB tunnels, detaches Frida, cleans Docker). This clearly distinguishes it from sibling tools like interceptor_android_deactivate or interceptor_kill.

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

Usage Guidelines4/5

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

The description labels it as 'Emergency cleanup', implying use when you need to stop everything immediately. It does not explicitly state when not to use or provide alternative tools, but the urgency context guides appropriate usage.

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

interceptor_docker_attachA

Inject proxy env vars and CA certificate into a Docker container. Two modes: 'exec' (inject into running container) or 'restart' (stop + restart with proxy config).

ParametersJSON Schema

Name	Required	Description	Default
`mode`	No	Injection mode: 'exec' (live injection) or 'restart' (stop + restart)	exec
`container_id`	Yes	Docker container ID or name

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description carries the burden of disclosure. It correctly indicates the tool modifies the container (injecting env vars and CA cert), and the 'restart' mode stops and restarts the container. However, it doesn't mention potential side effects, permissions required, or success/failure signals, which would enhance transparency.

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 concise: two sentences that front-load the core purpose and then detail the two modes. No redundant or unnecessary text.

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

Completeness2/5

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

Despite having no output schema, the description does not mention return values, error conditions, or what happens after injection (e.g., container remains running?). This lack of contextual information for a mutation tool is a notable gap, reducing completeness.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents both parameters. The description adds minimal value beyond schema: it rephrases the enum descriptions but does not explain what values to use or constraints. Baseline of 3 is appropriate as schema does the heavy lifting.

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 clearly states the tool's purpose: injecting proxy env vars and CA certificate into a Docker container. It distinguishes two modes ('exec' vs 'restart'), making it easy to understand the core operation and differentiate from siblings like interceptor_docker_detach.

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

Usage Guidelines3/5

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

The description explains the two modes and their basic behavior, but lacks guidance on when to choose one over the other or prerequisites (e.g., container must be running). No explicit 'when not to use' or alternative tools are mentioned, leaving some ambiguity.

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

interceptor_docker_detachA

Remove proxy configuration from a Docker container and clean up injected files.

ParametersJSON Schema

Name	Required	Description	Default
`target_id`	Yes	Target ID from interceptor_docker_attach

TDQS

A3.8/5.0

Behavior3/5

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

No annotations, so description carries burden. It discloses the removal and cleanup actions, but doesn't specify side effects, permissions, or prerequisites.

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?

Single sentence, no unnecessary words, front-loaded with action.

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

Completeness4/5

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

Given low complexity (one parameter, no output schema), the description is sufficient for understanding purpose and parameter origin. Minor omission: specifics of proxy configuration or files cleaned.

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

Parameters3/5

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

Schema coverage is 100% with description 'Target ID from interceptor_docker_attach'. Description does not add further meaning beyond the schema.

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?

Description clearly states the tool removes proxy configuration and cleans up injected files from a Docker container, distinguishing it from sibling interceptor_docker_attach which presumably adds such configuration.

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

Usage Guidelines3/5

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

No explicit guidance on when to use or alternatives. Implies use after attach, but no exclusions or context provided.

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

interceptor_frida_appsA

List running apps on an Android device via Frida. Requires frida-server running on the device.

ParametersJSON Schema

Name	Required	Description	Default
`serial`	Yes	ADB device serial

TDQS

A4/5.0

Behavior3/5

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 mentions the requirement for frida-server but does not disclose potential error states, performance implications, or that listing apps is a read-only operation. This is adequate but not thorough.

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 consists of two concise sentences with no redundant information. Every word serves a purpose, and it is well-structured.

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

Completeness4/5

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

Given the tool's simplicity (one parameter, no output schema), the description covers the essential aspects: functionality, prerequisite, and parameter. It could optionally describe the output format, but overall it is sufficiently complete for a low-complexity tool.

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

Parameters3/5

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

The input schema already provides a description for the single parameter 'serial' (ADB device serial), and the tool description adds no additional meaning beyond that. With 100% schema coverage, baseline 3 is appropriate.

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 clearly states the verb 'list', the resource 'running apps', and the method 'via Frida'. It effectively distinguishes itself from sibling tools like interceptor_frida_attach or interceptor_android_devices.

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

Usage Guidelines4/5

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

The description explicitly states the prerequisite 'Requires frida-server running on the device', which is critical for usage. However, it does not provide guidance on when to use this tool versus alternatives 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.

interceptor_frida_attachB

Attach to an Android app via Frida and inject SSL unpinning + proxy redirect scripts. Bypasses certificate pinning, OkHttp CertificatePinner, TrustManager, and native TLS verification.

ParametersJSON Schema

Name	Required	Description
`pid`	No	Process ID to attach to (alternative to app_name)
`serial`	Yes	ADB device serial
`app_name`	No	App process name or package identifier

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description should fully disclose behavioral traits. It states injection and bypassing, but omits important details: persistence, side effects (e.g., does it modify the app or system), error behaviors, and whether it requires root or specific Frida versions. This is a significant gap for a destructive-ish tool.

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

Conciseness4/5

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

Two concise sentences, front-loaded with action and purpose. No fluff, but could be slightly more structured (e.g., bullet points).

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

Completeness2/5

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

Given the tool's complexity (Frida attachment, SSL unpinning), the description lacks many contextual details: prerequisites (Frida server running?), effects on device, expected output, and error handling. With no output schema, users need more behavioral info.

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

Parameters3/5

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

Schema coverage is 100% with clear parameter descriptions. The tool description adds no extra meaning beyond the schema, such as explaining the choice between app_name and pid. Baseline 3 is appropriate.

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 clearly states the tool attaches to an Android app via Frida and injects SSL unpinning and proxy redirect scripts, specifying the exact action and resource. It distinguishes from siblings like interceptor_frida_apps (list apps) and interceptor_frida_detach (detach).

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?

No guidance on when to use this tool vs alternatives. It does not mention prerequisites, when not to use, or compare with interceptor_android_activate or other similar tools. Agents lack decision context.

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

interceptor_frida_detachA

Detach Frida session from an Android app, removing injected scripts.

ParametersJSON Schema

Name	Required	Description	Default
`target_id`	Yes	Target ID from interceptor_frida_attach

TDQS

A4/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses that the tool removes injected scripts, implying destructiveness. However, it does not mention failure cases, side effects (e.g., does it stop the Frida server?), or return behavior. Basic disclosure but incomplete.

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 a single sentence of 10 words with no extraneous information. It is front-loaded and every word earns its place. Perfectly concise for a simple tool.

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

Completeness4/5

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

Given the tool's low complexity (one parameter, no output schema, no annotations), the description is mostly adequate. It could mention that the session must be attached first (implied but not explicit) or the return value (success/failure). Minor gap, but largely complete.

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

Parameters4/5

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

The input schema has 100% coverage with a description for the only parameter. The description adds context by specifying that the target_id comes from interceptor_frida_attach, which is valuable linkage beyond the schema. Baseline 3 is exceeded with this extra guidance.

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 clearly states the verb 'Detach' and the resource 'Frida session from an Android app', and explains the action 'removing injected scripts'. It effectively distinguishes itself from the sibling tool 'interceptor_frida_attach' and other detach/cleanup tools.

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

Usage Guidelines3/5

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

The description implies usage after attaching a session via the parameter hint 'Target ID from interceptor_frida_attach', but does not explicitly state when to use this tool vs alternatives like interceptor_deactivate_all or interceptor_kill. No explicit 'when not to use' guidance is provided.

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

interceptor_killA

Kill a spawned process by target ID. Also retrieves final stdout/stderr output.

ParametersJSON Schema

Name	Required	Description	Default
`target_id`	Yes	Target ID from interceptor_spawn

TDQS

A4.2/5.0

Behavior4/5

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

No annotations provided, so description bears full responsibility. It discloses the key behavioral trait of retrieving final stdout/stderr output, which goes beyond a simple kill. However, it does not mention error handling or what happens if the target ID is invalid.

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?

Two short, front-loaded sentences with no extraneous words. The first sentence states the primary action, the second adds important context. Excellent brevity.

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

Completeness4/5

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

Given the simplicity of the tool (one parameter, no output schema), the description covers the main functionality adequately. It mentions output retrieval. Minor gaps include no mention of return format or behavior on invalid target ID, but overall sufficient.

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

Parameters3/5

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

Schema coverage is 100% and the parameter 'target_id' already has a clear description. The description adds no further semantic value beyond restating 'by target ID.' Baseline score of 3 is appropriate.

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?

Description clearly specifies the action: 'Kill a spawned process by target ID.' It also adds a side effect of retrieving final stdout/stderr. This distinguishes it from sibling tools like interceptor_spawn (creates) and interceptor_list (lists).

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

Usage Guidelines4/5

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

The description implies usage for terminating a process and retrieving its output. It references the target ID from interceptor_spawn, but does not explicitly state when not to use it or suggest alternatives. Still, the context is clear enough for an agent.

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

interceptor_listA

List all interceptors with their availability and active targets. Shows Browser, Terminal, Android ADB, Android Frida, and Docker interceptors.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior2/5

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

No annotations are provided, so the description carries the burden. It states what is listed but does not disclose behavioral traits like side effects, permissions, or read-only nature. Minimal behavioral info.

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?

Two concise sentences with front-loaded purpose. Every sentence adds value, no redundancy. Highly efficient.

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

Completeness4/5

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

For a simple list tool with no output schema, the description provides adequate context. It could elaborate on 'availability' or return format, but is sufficient for a basic list operation.

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

Parameters4/5

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

The input schema has zero parameters, so schema coverage is 100%. The description does not need to add parameter context; it adequately describes the function without parameter details.

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 clearly states the tool lists all interceptors with their availability and active targets, specifying five types. It distinguishes itself from sibling interceptor tools (e.g., interceptor_status) by being the only list tool.

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

Usage Guidelines3/5

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

The description implies usage for getting an overview of interceptors, but provides no guidance on when to use this tool versus alternatives like interceptor_status or interceptor_kill. No when-not or explicit context is given.

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

interceptor_spawnA

Spawn a command with proxy env vars pre-configured (HTTP_PROXY, HTTPS_PROXY, SSL_CERT_FILE, NODE_EXTRA_CA_CERTS, CURL_CA_BUNDLE, and 15+ more). Traffic automatically routes through the MITM proxy.

ParametersJSON Schema

Name	Required	Description
`cwd`	No	Working directory (default: current)
`env`	No	Additional env vars to set
`args`	No	Command arguments
`command`	Yes	Command to run (e.g., 'curl', 'node', 'python')

TDQS

A3.9/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It discloses that traffic routes through MITM proxy, but lacks details on command execution behavior (e.g., synchronous vs asynchronous, output handling) and required proxy state.

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?

Two sentences, no fluff. First sentence front-loads the core purpose; second adds key behavioral context. Highly efficient.

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?

Given 4 parameters and no output schema, description covers the basic purpose and one behavioral aspect, but omits critical details like return value, error handling, and dependency on proxy being active. Adequate but incomplete.

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

Parameters4/5

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

Input schema provides full coverage for all parameters. Description adds value by listing specific env variables (HTTP_PROXY, HTTPS_PROXY, etc.) and indicating there are more, enhancing parameter understanding beyond schema.

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?

Description clearly states it spawns a command with proxy env vars pre-configured. It distinguishes itself from sibling tools by focusing on running arbitrary commands with proxy settings, unlike browser or Android specific tools.

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

Usage Guidelines3/5

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

No explicit when-to-use or when-not-to-use guidance. It implies usage for running commands through the proxy, but does not mention alternatives or prerequisites like ensuring the proxy is running.

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

interceptor_statusB

Get detailed status of a specific interceptor, including all active targets and their details.

ParametersJSON Schema

Name	Required	Description	Default
`interceptor_id`	Yes	Interceptor ID (e.g., 'browser', 'terminal', 'android-adb', 'android-frida', 'docker')

TDQS

B3.4/5.0

Behavior3/5

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

No annotations exist, so description carries full burden. It correctly states the tool returns status and details of targets but does not disclose potential error conditions (e.g., invalid interceptor_id) or any side effects (likely none). Adequate but lacks depth.

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

Conciseness4/5

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

A single sentence that is concise and front-loaded with the key action and output. Could include more detail without being overly long, but current length is efficient.

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?

Given the lack of output schema and single parameter, the description provides a basic understanding but could be more specific about what 'detailed status' includes or hint at the structure of the response. It is marginally adequate.

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

Parameters3/5

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

Schema coverage is 100%, so description adds minimal extra meaning beyond the parameter name and examples provided in the schema. The description does not elaborate on the parameter beyond what is in the schema.

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 clearly states the verb 'Get', the resource 'detailed status of a specific interceptor', and scope 'including all active targets and their details'. It distinguishes itself from sibling tools like interceptor_list (which likely lists interceptors) by focusing on a single interceptor's status.

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?

No guidance on when to use this tool versus alternatives (e.g., interceptor_list for listing all interceptors, or other interceptor-specific tools). It does not mention prerequisites or avoid cases.

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

proxy_add_ruleB

Add an interception rule with a matcher and handler. Rules are evaluated by priority (ascending), first match wins.

ParametersJSON Schema

Name	Required	Description
`handler`	Yes	What to do with matched requests
`matcher`	Yes	Conditions to match requests
`priority`	No	Priority (lower = higher priority, default: 100)
`description`	Yes	Human-readable description of this rule

TDQS

B3.3/5.0

Behavior3/5

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

With no annotations, the description must disclose behavioral traits. It mentions evaluation order (priority ascending, first match wins) which is useful. However, it does not discuss side effects, limits, or idempotency, which would be expected for a creation tool.

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

Conciseness4/5

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

The description is brief (two sentences) and front-loaded with the main action. However, it could be structured more clearly, perhaps listing the required components separately. Still, it is not verbose.

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

Completeness2/5

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

The tool has complex nested parameters and no output schema. The description is minimal and does not explain what the tool returns (e.g., rule ID) or how it handles duplicate descriptions or priority conflicts. More context is needed for an agent to use it correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema; it just mentions 'matcher and handler' which are already defined in detail in the schema.

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 clearly states the action (add), the resource (interception rule), and its components (matcher and handler). It also mentions evaluation order (priority ascending, first match wins), distinguishing it from sibling tools like proxy_update_rule or proxy_remove_rule.

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?

No guidance on when to use this tool versus alternatives. For example, it does not say to use proxy_update_rule for modifying existing rules or proxy_test_rule_match for testing. The description only states what the tool does, not when it is appropriate.

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

proxy_check_fingerprint_runtimeA

Check fingerprint spoofing backend readiness without sending traffic.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description must fully convey behavioral traits. It states the tool checks readiness without sending traffic, indicating safety, but it omits details such as whether the check is idempotent, what 'readiness' entails, any required preconditions, or possible side effects. This is insufficient for a mutation-related backend feature.

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?

A single, front-loaded sentence that effectively communicates the tool's core function. No extraneous words; every part earns its place.

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?

Given the tool has no parameters, no output schema, and no annotations, the description is minimal. It states the action but does not explain what 'readiness' means or how the result is structured. For a simple check tool, this is adequate but could be more helpful by clarifying the outcome.

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

Parameters4/5

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

The input schema has no parameters (0 params, 100% coverage). Per the baseline rule, a score of 4 is appropriate because the description adds no extra parameter information but does not need to compensate for schema gaps. The description could have explained the concept of 'fingerprint runtime' but is not required to.

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 clearly specifies the verb 'check', the resource 'fingerprint spoofing backend readiness', and adds the distinguishing detail 'without sending traffic'. This differentiates it from sibling tools like proxy_set_fingerprint_spoof or proxy_list_fingerprint_presets, which have different purposes.

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

Usage Guidelines3/5

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

The phrase 'without sending traffic' implies a non-disruptive read operation, but no explicit guidance is given on when to use this tool versus alternatives like proxy_set_fingerprint_spoof. It doesn't specify prerequisites or expected context, 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.

proxy_clear_ja3_spoofB

Disable fingerprint spoofing.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations present, the description carries the full burden of behavioral disclosure. It merely says 'disable' but does not explain side effects, reversibility, state changes, or whether it affects other proxy settings. This lack of detail is insufficient for a tool that modifies proxy behavior.

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

Conciseness4/5

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

The description is a single short sentence with no filler, making it very concise. However, it lacks any structure beyond that, such as separation of concerns or additional helpful context.

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?

Given the tool has no parameters and no output schema, the description is adequate for a simple toggle action, but it does not address potential side effects or the broader context within the proxy toolset. It misses opportunities to explain what fingerprint spoofing is or how to revert the action.

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

Parameters4/5

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

There are no parameters (0 params, 100% schema coverage), so the description does not need to add parameter details. According to the rubric, 0 params yields a baseline score of 4.

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 'Disable fingerprint spoofing' clearly states the action (disable) and the resource (fingerprint spoofing). The name includes 'ja3_spoof', which is a type of fingerprint, making the purpose very specific and distinguishable from sibling tools like proxy_set_ja3_spoof.

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?

No guidance is provided on when to use this tool versus its siblings, such as proxy_set_ja3_spoof or proxy_check_fingerprint_runtime. The description does not mention prerequisites, alternatives, or contextual triggers for disabling spoofing.

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

proxy_clear_trafficA

Clear all captured traffic from the buffer.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.6/5.0

Behavior2/5

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

Minimal disclosure beyond the verb 'clear', which implies destruction but lacks details on side effects, reversibility, or impact on other tool states. No annotations to supplement.

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?

Extremely concise single sentence that communicates the core function with no waste.

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

Completeness4/5

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

For a zero-parameter tool, the description is adequate, though it lacks behavioral nuance. Could mention that traffic is permanently cleared, but not necessary for basic understanding.

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

Parameters4/5

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

No parameters exist, so the description does not need to add parameter semantics. Baseline score of 4 is appropriate.

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 specifies a clear action ('clear') and resource ('captured traffic from the buffer'), distinguishing it from sibling tools like proxy_list_traffic or proxy_export_har.

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?

No guidance on when to use this tool versus alternatives. Does not mention prerequisites, side effects, 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.

proxy_clear_upstreamA

Remove the global upstream proxy. Traffic will go directly to target servers.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior3/5

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

No annotations provided. Description states effect (traffic goes directly) but no side effects or prerequisites. Adequate for a simple clear operation.

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?

Two concise sentences, front-loaded with action. No wasted words.

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?

Minimal but covers primary action. Lacks mention of return value, error conditions, or relationship to proxy_set_upstream. Adequate for simple tool.

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

Parameters3/5

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

No parameters; schema coverage 100%. Description adds no parameter info, which is acceptable as no parameters exist.

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?

Description uses clear verb 'Remove' and specifies 'global upstream proxy', distinguishing it from siblings like proxy_set_upstream and proxy_remove_host_upstream.

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

Usage Guidelines3/5

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

Implies usage when removing global upstream proxy, but no explicit guidance on when to use vs alternatives like proxy_remove_host_upstream.

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

proxy_delete_sessionA

Delete a recorded session from disk.

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	Yes	Session ID

TDQS

A3.5/5.0

Behavior3/5

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

States deletion from disk, implying permanence, but lacks details about behavior if session is active, whether it's safe to call while proxy is running, or any side effects. No annotations to supplement, so description carries burden but is incomplete.

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?

Single sentence with no redundant or extraneous information. Efficiently communicates core action and resource.

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?

While simple, the description omits preconditions (e.g., session must be stopped) and postconditions (e.g., session data cannot be recovered). For a destructive operation, more context would help an agent avoid errors. Output schema not present, so description could provide more return value context.

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

Parameters3/5

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

Input schema has 100% description coverage with 'Session ID' for the single parameter. The tool description adds no additional meaning beyond what the schema already provides, so baseline score of 3 applies.

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?

Specific verb 'Delete' and resource 'recorded session from disk' clearly indicates purpose. Distinguishes from sibling tools like proxy_get_session, proxy_list_sessions, and proxy_session_start which perform different operations.

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?

No guidance on when to use this tool versus alternatives like proxy_session_stop (which stops but doesn't delete) or proxy_session_start (which creates). Does not mention prerequisites (e.g., session must be inactive) or that deletion is irreversible.

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

proxy_disable_ruleA

Disable an interception rule without removing it.

ParametersJSON Schema

Name	Required	Description	Default
`rule_id`	Yes	Rule ID to disable

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It correctly notes that the rule is not removed, implying nondestructive behavior. However, it does not specify side effects, reversibility, or whether the action affects active sessions. Basic transparency is present but could be richer.

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 a single, focused sentence that conveys the essential action without extraneous words. It is well-structured and front-loaded.

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

Completeness4/5

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

Given the low complexity, single parameter, and no output schema, the description covers the core functionality. However, it could benefit from slightly more context (e.g., relation to enable/remove) but is sufficient for the tool's simplicity.

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

Parameters3/5

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

Schema coverage is 100% with one parameter (rule_id) adequately described. The description adds no additional meaning beyond the schema. Baseline 3 is appropriate as the schema does the heavy lifting.

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 clearly states the verb 'disable' and the resource 'interception rule', and adds specificity 'without removing it' which distinguishes it from proxy_remove_rule. Sibling tools like proxy_enable_rule and proxy_remove_rule further differentiate the action.

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

Usage Guidelines3/5

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 versus alternatives like proxy_remove_rule or proxy_enable_rule. While the context of sibling tools implies usage scenarios, the description itself lacks guidance on exclusions or prerequisites.

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

proxy_enable_ruleA

Enable a disabled interception rule.

ParametersJSON Schema

Name	Required	Description	Default
`rule_id`	Yes	Rule ID to enable

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It only states the basic action without disclosing behavioral traits (e.g., reversibility, idempotence, what happens if already enabled). 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.

Conciseness5/5

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

The description is a single sentence with no superfluous words, achieving maximum conciseness while conveying the core purpose.

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?

For a simple one-parameter tool, the description is adequate but lacks contextual completeness. It does not mention that the rule must be disabled first, nor does it hint at the relationship with proxy_disable_rule.

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

Parameters3/5

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

The single parameter (rule_id) is already described in the input schema with 100% coverage. The description adds no additional meaning beyond the schema.

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 clearly states the action 'enable' and the resource 'a disabled interception rule', making the tool's purpose immediately obvious. It distinguishes well from siblings like proxy_disable_rule and proxy_update_rule.

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

Usage Guidelines3/5

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

The description implies usage (enable a rule that is disabled) but provides no explicit context about when to use this tool versus alternatives. No mention of prerequisites or scenarios.

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

proxy_enable_server_tls_captureA

Toggle server-side JA3S capture. When enabled, outgoing TLS connections are intercepted to extract the server's negotiated TLS parameters.

ParametersJSON Schema

Name	Required	Description	Default
`enabled`	Yes	true to enable, false to disable

TDQS

A4/5.0

Behavior3/5

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

No annotations are present, so the description carries the full burden. It explains the effect (intercept outgoing TLS, extract negotiated parameters) but does not disclose potential side effects like performance impact or how captured data is stored/retrieved.

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?

Two concise sentences that front-load the action and then describe the effect. No unnecessary words; every sentence is informative.

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

Completeness4/5

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

For a simple toggle tool with one parameter, the description is nearly complete. It explains what capture does but could mention that extracted data is accessible via other proxy tools (e.g., proxy_get_tls_fingerprints). Minor gap.

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

Parameters3/5

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

Schema coverage is 100% with a well-described boolean parameter. The description adds the concept of 'toggling' but no additional meaning beyond what the schema already provides. Baseline score of 3 applies.

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 uses specific verb 'Toggle' and resource 'server-side JA3S capture', clearly distinguishing it from sibling tools like proxy_set_ja3_spoof. It states exactly what the tool does.

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

Usage Guidelines4/5

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

The description implies usage context (enable to intercept TLS connections) but does not explicitly state when not to use it or mention alternatives. It provides clear context for when to toggle capture.

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

proxy_export_harC

Export a recorded session (or filtered subset) to HAR format.

ParametersJSON Schema

Name	Required	Description	Default
`sort`	No		asc
`text`	No
`to_ts`	No
`method`	No
`from_ts`	No
`session_id`	Yes	Session ID
`output_file`	No	Output HAR file path
`status_code`	No
`url_contains`	No
`include_bodies`	No	Include body text when available
`hostname_contains`	No

TDQS

C2.4/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose important behavioral traits like whether it overwrites existing files, file size limits, or side effects on the session. This leaves the agent uninformed about critical behavior.

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

Conciseness3/5

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

The description is concise at one sentence, but it is too terse given the complexity of the tool. It could benefit from a brief additional sentence on the filtering capability.

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

Completeness2/5

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

Given the high parameter count and lack of output schema, the description is incomplete. It does not explain optional filters, output format details, or prerequisite steps, leaving gaps for the agent.

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

Parameters1/5

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

With schema description coverage at only 27%, the description should compensate but merely mentions 'filtered subset' without explaining any of the 11 parameters. It adds no value beyond what the minimal schema provides.

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

Purpose4/5

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

The description clearly states the tool exports a recorded session to HAR format. However, it does not explicitly differentiate from sibling tools like proxy_import_har beyond the direction (export vs import).

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?

No guidance is provided on when to use this tool versus alternatives, such as proxy_import_har or proxy_list_traffic. The description lacks context for decision-making.

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

proxy_get_ca_certA

Get the CA certificate PEM and SPKI fingerprint for installing on the target device.

ParametersJSON Schema

Name	Required	Description	Default
`format`	No	What to return: 'pem', 'fingerprint', or 'both'	both

TDQS

A4.1/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It describes a read operation ('Get'), which is transparent. But no mention of permissions, side effects, or error conditions, leaving some gaps.

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?

Single sentence, no redundant words, front-loaded with action and resource. Perfectly concise.

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

Completeness5/5

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

For a simple one-parameter getter with no output schema, the description is complete: it tells what, why, and the format options are clear from schema. Siblings indicate it fits into proxy setup workflow.

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

Parameters3/5

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

Schema covers format parameter 100% with enum and default. Description does not add extra meaning beyond 'PEM and SPKI fingerprint'. Baseline 3 applies due to high schema coverage.

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 clearly states the specific verb 'get' and the resource 'CA certificate PEM and SPKI fingerprint', with clear purpose 'for installing on the target device'. This distinguishes it from sibling tools like proxy_set_* or proxy_start.

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

Usage Guidelines4/5

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

The phrase 'for installing on the target device' provides usage context, indicating this is a setup step. However, no explicit guidance on when to use vs alternatives (e.g., proxy_check_fingerprint_runtime) is given.

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

proxy_get_exchangeB

Get full details of a captured HTTP exchange including headers and body previews.

ParametersJSON Schema

Name	Required	Description	Default
`exchange_id`	Yes	Exchange ID from proxy_list_traffic

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It only states the tool returns full details with headers and body previews, but omits behavioral traits like whether the tool is read-only, any size limits, or response truncation.

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?

Single sentence, 12 words, front-loaded with key information. Every word contributes to the purpose.

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?

Adequate for a simple retrieval tool with one parameter, but lacks details on what 'full details' entails (e.g., whether body previews are truncated) and no output schema is provided. Gaps remain.

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

Parameters3/5

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

Schema coverage is 100% with the parameter exchange_id described as 'Exchange ID from proxy_list_traffic'. Description adds 'full details' but no additional meaning beyond schema; baseline 3 is appropriate.

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?

Description clearly states the verb 'get', the resource 'details of a captured HTTP exchange', and what is included ('headers and body previews'), distinguishing it from sibling tools like proxy_list_traffic.

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?

No explicit guidance on when to use this tool versus alternatives. The prerequisite (exchange_id from proxy_list_traffic) is implied by the schema but not stated, and no when-not-to-use or exclusion criteria are provided.

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

proxy_get_sessionB

Get manifest/details for a specific recorded session.

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	Yes	Session ID

TDQS

B3.2/5.0

Behavior2/5

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

Since no annotations are available, the description bears full responsibility for behavioral disclosure. It mentions a read operation ('Get') but provides no details about side effects, authentication requirements, rate limits, or other behavioral traits.

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

Conciseness4/5

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

The description is a single, concise sentence with no filler. However, it could be slightly expanded to include usage hints without becoming verbose.

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?

The tool is simple (one parameter, no output schema), and the description adequately conveys its purpose. However, given the absence of an output schema, some indication of what the response contains would improve completeness.

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

Parameters3/5

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

The input schema includes one parameter (session_id) with full description coverage (100%). The tool description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.

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 clearly states the tool retrieves manifest or details for a specific recorded session, using a specific verb and resource. It distinguishes itself from siblings like proxy_list_sessions (which lists sessions) and proxy_get_session_exchange (which gets individual exchanges).

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?

No guidance is provided on when to use this tool versus alternatives such as proxy_get_exchange or proxy_get_session_handshakes. The description does not specify context, prerequisites, or exclusions.

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

proxy_get_session_exchangeB

Get one exchange from a recorded session by seq or exchange ID.

ParametersJSON Schema

Name	Required	Description
`seq`	No	Sequence number in session
`session_id`	Yes	Session ID
`exchange_id`	No	Original exchange ID
`include_body`	No	Include persisted full body data when available

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description must fully disclose behavioral traits, but it only states 'get one exchange'. It does not indicate whether the operation is read-only (likely), what happens if the exchange is not found, or any side effects. The description adds no behavioral context beyond the schema.

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 a single, well-structured sentence of 10 words that conveys the core purpose efficiently. It contains no unnecessary information and is front-loaded with the action and resource.

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?

Given the tool has 4 parameters, no output schema, and no annotations, the description is minimally adequate. It explains the basic retrieval function but lacks context on what an 'exchange' is, how sessions work, or typical use cases. With full schema coverage, it meets the minimum but leaves gaps.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema; it merely restates that identification is by seq or exchange ID, which is already evident from the parameter descriptions. No extra constraints or relationships are provided.

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 clearly states the tool retrieves one exchange from a recorded session, specifying the identification methods (by seq or exchange ID). This verb+resource combination is specific and distinguishes it from sibling tools like proxy_get_exchange which likely operates without session context.

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?

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions. The description merely states what it does, leaving the agent to infer usage from the tool name alone.

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

proxy_get_session_handshakesC

Summarize TLS handshake/fingerprint availability (JA3/JA4/JA3S) for session exchanges.

ParametersJSON Schema

Name	Required	Description	Default
`sort`	No		desc
`limit`	No
`offset`	No
`session_id`	Yes	Session ID
`url_contains`	No	Filter by URL substring
`hostname_contains`	No	Filter by hostname substring

TDQS

C2.7/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It does not disclose read-only nature, side effects, authentication needs, rate limits, or return format. The word 'summarize' hints at non-destructive behavior, but no details 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.

Conciseness4/5

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

The description is a single concise sentence that front-loads the primary purpose. No wasted words, but it could be slightly more structured with additional details.

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

Completeness2/5

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

For a tool with 6 parameters, no output schema, and no annotations, the description is insufficient. It does not describe the output format or the meaning of the summary, leaving agents underinformed.

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

Parameters2/5

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

Schema description coverage is 50%, leaving limit, offset, and sort undocumented. The description adds no parameter information, failing to compensate for the gap. It does not explain how these parameters affect the summary.

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

Purpose4/5

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

The description clearly states the tool summarizes TLS handshake/fingerprint availability (JA3/JA4/JA3S) for session exchanges, which distinguishes it from sibling tools like proxy_get_tls_fingerprints and proxy_get_session_exchange. However, it does not define 'availability' precisely.

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?

No guidance on when to use this tool versus alternatives. The description lacks prerequisites, use-case context, or exclusions. With no annotations, the description must provide this, but it does not.

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

proxy_get_tls_configA

Get current TLS capture and spoofing configuration.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It correctly indicates a read operation ('Get'), implying no side effects. No contradiction, but could add details like return format or prerequisites.

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?

A single, front-loaded sentence that efficiently communicates the tool's purpose. No unnecessary words.

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

Completeness4/5

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

For a simple getter tool with no parameters and no output schema, the description is adequate. It could be enriched with details about the returned configuration, but it is sufficient for an AI agent to understand the basic function.

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

Parameters4/5

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

The tool has no parameters, so the schema fully covers them. The description adds no additional semantic detail, but none is needed. Baseline 4 is appropriate.

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 clearly states the tool gets the current TLS capture and spoofing configuration, with a specific verb and resource. It distinguishes from sibling tools that modify or manage proxies and TLS settings.

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

Usage Guidelines4/5

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

The description makes the purpose clear (retrieving config), providing implicit guidance for usage. However, it lacks explicit when-to-use or when-not-to-use instructions, and does not mention alternatives.

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

proxy_get_tls_fingerprintsA

Get JA3/JA4 client fingerprints and JA3S server fingerprint for a specific captured exchange.

ParametersJSON Schema

Name	Required	Description	Default
`exchange_id`	Yes	Exchange ID from proxy_list_traffic

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. However, it only states the function (get fingerprints) without mentioning any side effects, required permissions, or output details. For a read-only operation, this is minimal but could be improved by noting that it is non-destructive.

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 a single, concise sentence that conveys the core functionality without any unnecessary words. It is front-loaded with the action and resource, making it easy to parse quickly.

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?

Given the tool's simplicity (one parameter, no output schema), the description is reasonably complete. However, it lacks information about the return format (e.g., object with fingerprint strings) or prerequisites (e.g., the exchange must exist). An output schema or brief note on output structure would improve completeness.

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

Parameters3/5

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

The input schema has 100% description coverage, with the parameter 'exchange_id' already described as 'Exchange ID from proxy_list_traffic'. The tool description does not add any further semantic meaning to the parameter beyond what the schema provides, so a baseline score of 3 is appropriate.

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 clearly identifies the tool's purpose: retrieving JA3, JA4, and JA3S fingerprints for a specific captured exchange. The verb 'Get' and the specific resource types (client and server fingerprints) differentiate it from sibling tools like proxy_list_tls_fingerprints (which lists all fingerprints) and proxy_list_traffic (which lists exchanges).

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

Usage Guidelines3/5

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

The description implies that the tool should be used when you have a specific exchange_id from proxy_list_traffic, but it does not explicitly state when to use it versus alternatives. For example, it could clarify that proxy_list_tls_fingerprints might be used first to get an overview, or that this tool provides details for a single exchange. No exclusion criteria are provided.

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

proxy_import_harA

Import a HAR file from disk into a new persisted session for querying, findings, and replay.

ParametersJSON Schema

Name	Required	Description
`strict`	No	When true, abort on first invalid HAR entry; when false, skip invalid entries
`har_file`	Yes	Path to HAR file on disk
`max_disk_mb`	No	Session disk cap in MB
`storage_dir`	No	Optional custom session storage directory
`session_name`	No	Optional name for the imported session

TDQS

A3.5/5.0

Behavior2/5

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 lacks disclosure of behavioral traits such as whether existing sessions are overwritten, error handling for malformed HAR files (though 'strict' parameter hints at this in schema), or details about session persistence. For a mutation tool, more behavioral context is needed.

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 a single sentence that fronts the action and outcome, containing no unnecessary words. It is concise and structured efficiently.

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?

Given the tool's complexity (5 parameters, no output schema), the description provides the high-level purpose but lacks details about return values (e.g., session ID) and edge cases. It is adequate but not fully comprehensive.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description does not add additional meaning beyond the schema; it does not elaborate on parameter nuances like session naming or storage directory behavior.

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 clearly states the action (import), the resource (HAR file), and the destination (new persisted session). It also indicates the purpose (querying, findings, replay), distinguishing it from sibling tools like proxy_export_har or proxy_list_sessions.

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

Usage Guidelines3/5

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

The description implies usage when a HAR file needs to be imported into a session, but does not provide explicit guidance on when to use this tool versus alternatives, nor when not to use it. No exclusions or alternatives are mentioned.

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

proxy_inject_headersA

Add or overwrite headers on matching traffic. Creates a passthrough rule with header transforms.

ParametersJSON Schema

Name	Required	Description	Default
`headers`	Yes	Headers to inject (key-value pairs, set value to null to delete a header)
`hostname`	No	Hostname to match (optional)
`priority`	No	Rule priority (default: 50)
`direction`	No	Where to inject: request, response, or both	request
`url_pattern`	No	URL regex pattern to match (optional)

TDQS

A3.8/5.0

Behavior3/5

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

No annotations provided, so description must cover behavioral traits. It discloses it's a passthrough rule with header transforms but omits side effects like rule activation timing, overwrite behavior, or permission requirements. Lacks full transparency.

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?

Two succinct sentences, front-loaded with main purpose, no redundant words. Every sentence adds value.

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

Completeness4/5

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

Given the tool's moderate complexity and high schema coverage, the description captures the essence and differentiates from siblings. Lacks mention of return behavior but no output schema expected. Still sufficiently complete.

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

Parameters3/5

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

Schema coverage is 100%, so schema already documents all parameters. Description adds minimal extra context (e.g., 'passthrough rule'), which warrants a baseline 3. No significant additional explanation beyond schema.

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?

Description clearly states verb 'Add or overwrite headers' and resource 'matching traffic', and specifies it creates a passthrough rule. This distinguishes it from sibling tools like proxy_add_rule or proxy_rewrite_url.

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

Usage Guidelines3/5

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

Description implies usage for header injection on matching traffic but lacks explicit guidance on when to use this vs alternatives like proxy_add_rule with transforms. No when-not-to-use or prerequisites mentioned.

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

proxy_list_fingerprint_presetsA

List available browser fingerprint presets for use with proxy_set_fingerprint_spoof.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavioral traits. It only says 'list available', with no mention of side effects, permissions, or state changes. For a read-only listing tool, the absence of any explicit statement about non-destructiveness is a gap.

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 a single, clean sentence with no extra words. It front-loads the action and purpose, making it highly efficient.

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?

For a parameterless listing tool with no output schema, the description provides the basic purpose. However, it lacks details about what the output looks like (e.g., list of strings, objects) and any usage context, making it minimally adequate.

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

Parameters4/5

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

The input schema has no parameters, so the baseline is 4. The description does not add further meaning, but since there are no parameters, no additional information is strictly needed.

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 clearly states 'List available browser fingerprint presets', specifying the verb 'list' and the resource 'browser fingerprint presets'. It also indicates the purpose 'for use with proxy_set_fingerprint_spoof', distinguishing it from sibling tools that set or check fingerprints.

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?

The description only hints at usage with proxy_set_fingerprint_spoof but does not provide explicit guidance on when to use this tool or when to avoid it. No alternatives are mentioned, and with many sibling tools, more context is needed.

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

proxy_list_rulesA

List all interception rules sorted by priority.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden. It states it lists all rules sorted by priority, implying a read-only operation. While it doesn't explicitly confirm no side effects, the verb 'list' strongly suggests safe behavior.

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 a single concise sentence of 7 words that perfectly captures the tool's function with no superfluous information. It is front-loaded and efficient.

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

Completeness5/5

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

Given the tool's low complexity (no parameters, simple list operation), the description is complete. It covers what the tool does and the ordering. No output schema exists, but the behavior is straightforward enough that further detail is unnecessary.

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

Parameters4/5

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

The tool has zero parameters, so the schema coverage is 100%. Per guidelines, baseline for 0 parameters is 4. The description adds no parameter information because none exist.

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 uses a specific verb ('List') and resource ('interception rules'), and clearly states the ordering by priority. This distinguishes it from sibling tools that add, remove, or modify rules.

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

Usage Guidelines3/5

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

The description implicitly indicates this tool is for reading rules, but does not provide explicit guidance on when to use it versus alternatives (e.g., proxy_get_session for sessions). No when-not-to-use or alternative mentions are given.

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

proxy_list_sessionsA

List recorded sessions in storage.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations, the description carries full burden. It only states 'list recorded sessions' with no behavioral details such as whether the list includes metadata, supports pagination, or how sessions are ordered. Minimal disclosure beyond the core purpose.

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

Conciseness4/5

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

At six words, the description is highly concise and front-loaded. However, slightly more context about the nature of 'sessions' could improve understanding without bloating the text.

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

Completeness2/5

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

Given the lack of an output schema and the presence of many sibling session-related tools (e.g., 'proxy_list_traffic', 'proxy_get_session'), the description fails to explain what information is returned (e.g., session IDs, timestamps) or how this tool differs from similar listing tools.

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

Parameters4/5

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

There are zero parameters and schema coverage is 100% (empty schema). The description need not add parameter details, and the baseline for no parameters is 4. No param information is required.

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 clearly states the verb 'list' and the resource 'recorded sessions', making the purpose unambiguous. It also distinguishes from sibling tools like 'proxy_get_session' (individual session retrieval) and 'proxy_delete_session' (deletion).

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

Usage Guidelines3/5

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

The description implies listing all sessions, but it does not provide explicit guidance on when to use this tool versus alternatives like 'proxy_query_session' or 'proxy_get_session'. No context about filtering or usage conditions is given.

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

proxy_list_tls_fingerprintsB

List unique client JA3/JA4 fingerprints across captured traffic with occurrence counts.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Max fingerprints to return (default: 20)
`hostname_filter`	No	Filter by hostname substring

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It does not state whether the operation is read-only, if it affects capture state, or what scope of traffic is considered (e.g., current session only). The agent cannot infer safety or side effects.

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 a single, concise sentence that is front-loaded with the core purpose. Every word adds value; no unnecessary information.

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?

The description covers the basic functionality adequately for a simple tool with 2 optional parameters and no output schema. However, it lacks context such as read-only nature or that it operates on the current capture session. Sibling tool count is high but not addressed.

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

Parameters3/5

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

Schema coverage is 100% with both parameters described. The description adds no additional parameter semantics beyond the schema, but it does mention 'occurrence counts' in the output, which is helpful. Baseline 3 is appropriate.

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 clearly states the verb 'list' and the resource 'unique client JA3/JA4 fingerprints' with additional detail 'occurrence counts'. It distinguishes itself from sibling tools like proxy_get_tls_fingerprints (which likely returns specific details) and proxy_list_fingerprint_presets (presets vs captured traffic).

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?

The description provides no guidance on when to use this tool versus alternatives (e.g., proxy_get_tls_fingerprints) nor mentions prerequisites like an active capture session. There is no explicit 'when not to use' or context for selection.

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

proxy_list_trafficC

List captured HTTP exchanges with optional filters. Returns paginated results.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max entries to return (default: 50)
`offset`	No	Skip first N entries (default: 0)
`url_filter`	No	Filter by URL substring
`method_filter`	No	Filter by HTTP method (e.g., GET, POST)
`source_filter`	No	Filter by traffic source: 'explicit' (proxy-configured) or 'transparent' (iptables-redirected)
`status_filter`	No	Filter by response status code
`hostname_filter`	No	Filter by hostname substring

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It only states 'returns paginated results' without mentioning read-only nature, ordering, error handling, or side effects. The lack of detail limits an agent's understanding of the tool's behavior.

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 a single sentence that efficiently conveys the core purpose, verb, resource, and key features (filters, pagination). No redundant words, well-structured and front-loaded.

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

Completeness2/5

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

For a list tool with 7 optional filters and pagination, the description lacks details about filter combination logic (AND/OR), pagination structure (e.g., total count), and output format. With no output schema, the description should provide more context to be complete.

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

Parameters3/5

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

All 7 parameters have schema descriptions, achieving 100% schema coverage. The tool description adds no extra semantic value beyond summarizing that filters are optional. Baseline 3 is appropriate as the description does not enhance parameter understanding.

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

Purpose4/5

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

The description clearly states the verb 'list' and the resource 'captured HTTP exchanges', and mentions optional filters and pagination. It distinguishes from similar siblings like 'proxy_search_traffic' by using 'list' rather than 'search', but does not explicitly differentiate from other list tools like 'proxy_list_sessions'.

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?

No guidance on when to use this tool versus alternatives. No mention of when to apply filters or how pagination works. The description is too terse to inform an AI agent about appropriate usage scenarios.

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

proxy_mobile_detect_ifaceA

Auto-detect the USB-NCM interface the proxy-ap-card presents as (via the cdc_ncm driver). Returns null + iface list if none found.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior3/5

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

Description discloses return behavior (null+list if none found) but no annotations exist. Could mention whether detection is instantaneous or blocking, though probably safe.

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?

Single sentence with all key info: action, mechanism, return format. No wasted words.

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

Completeness4/5

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

For a zero-param detection tool, description covers purpose and output. Could mention typical use case (mobile proxy setup) but not strictly necessary.

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

Parameters4/5

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

No parameters, so description needs no param details. Schema coverage is 100% (zero params), baseline 4 applies.

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?

Description clearly states the tool auto-detects the USB-NCM interface, a specific action. It's a verb+resource pair, and distinct from sibling tools which are mostly unrelated.

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?

No guidance on when to use this tool vs alternatives. No mention of prerequisites or context (e.g., before proxy_mobile_setup). Agent lacks decision help.

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

proxy_mobile_setupA

One-command mobile capture: start explicit + transparent listeners, optionally inject the CA on an Android device, and emit a sudo-runnable script that wires iptables/sysctl/nmcli on the AP iface. Designed to pair with the proxy-ap-card firmware (ESP32-S3 rogue AP over USB-NCM).

ParametersJSON Schema

Name	Required	Description	Default
`ap_iface`	No	AP/USB interface name. Auto-detected via cdc_ncm driver if omitted.
`ap_subnet`	No	Subnet the AP serves to clients (default: 192.168.4.0/24, matches proxy-ap-card firmware).	192.168.4.0/24
`ap_address`	No	Laptop-side address on the AP iface (default: 192.168.99.2/24, matches proxy-ap-card firmware).	192.168.99.2/24
`block_quic`	No	Drop UDP/443 on the AP iface so apps fall back to TCP/TLS (capturable). Default: true.
`inject_cert`	No	Inject the CA into the Android device's system store. Ignored if android_serial is omitted.
`egress_iface`	No	Host's internet-facing iface. Auto-detected from /proc/net/route if omitted.
`explicit_port`	No	Port for the explicit HTTP proxy (default: 8080).
`android_serial`	No	ADB serial of an Android device to inject the CA on. If omitted, no cert injection is attempted.
`transparent_port`	No	Port for the transparent HTTPS listener (default: 8443).
`upstream_proxy_url`	No	Optional upstream proxy URL (socks5://user:pass@host:port or http://...). Sets the global upstream for BOTH listeners. If it has a username but no password, the password is filled in from PROXY_MCP_UPSTREAM_PASSWORD, but only when PROXY_MCP_UPSTREAM_HOST is also set and matches this URL's hostname. The response reports password_source: env \| url \| none.

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description carries full burden for side-effect disclosure. It does disclose that the tool starts listeners, may inject a CA on an Android device, and emits a script that modifies iptables/sysctl/nmcli. However, it leaves ambiguity about whether the script is executed or merely emitted, and does not mention host sudo requirements or potential persistence of network changes.

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

Conciseness4/5

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

Two sentences with no filler, front-loading the core value proposition. The first sentence is dense but organized as a clear enumerated list of actions, and the second sentence adds crucial hardware context that justifies the tool's purpose.

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

Completeness2/5

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

This is a complex 10-parameter orchestration tool with no output schema and no annotations, yet the description remains high-level. It does not explain what the tool returns, whether the sudo script is executed or merely output for the user, or how it relates to proxy_mobile_teardown for cleanup. An agent invoking this tool would be uncertain about the result and subsequent steps.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description adds workflow-level context that loosely maps to parameters (explicit/transparent listeners, AP iface, CA injection), but it does not add syntax, defaults, or behaviors beyond what the schema already provides.

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 names a specific action ('start explicit + transparent listeners'), an optional CA injection, and a script emission that wires iptables/sysctl/nmcli. This clearly distinguishes the tool from siblings like proxy_start_transparent (transparent-only) and proxy_mobile_teardown (teardown), even without naming them explicitly.

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

Usage Guidelines3/5

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

The description clearly implies the intended use case: one-command mobile capture paired with the proxy-ap-card firmware. However, it does not explicitly state when not to use this tool or name alternatives, such as proxy_start_transparent for transparent-proxy-only needs.

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

proxy_mobile_teardownA

Reverse proxy_mobile_setup: deactivate the Android target if any, stop the transparent + explicit listeners, and emit a sudo-runnable script that removes the iptables rules and restores NetworkManager management.

ParametersJSON Schema

Name	Required	Description	Default
`ap_iface`	No	AP/USB interface name. Auto-detected via cdc_ncm if omitted.
`ap_subnet`	No	Subnet the AP serves (must match setup).	192.168.4.0/24
`block_quic`	No	Whether the QUIC DROP rule was set up (so we know to remove it).
`stop_proxy`	No	Also stop the explicit proxy (default: keep it running for continued use).
`egress_iface`	No	Host's egress iface (must match setup).
`android_target_id`	No	Android target ID to deactivate (from proxy_mobile_setup response).

TDQS

A4.2/5.0

Behavior4/5

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

The description discloses key side effects: deactivating Android target, stopping listeners, and emitting a sudo-runnable script that modifies iptables and NetworkManager. Without annotations, this provides good transparency, though it is unclear whether the script is auto-executed or just emitted.

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?

A single sentence that is front-loaded with the core purpose ('Reverse proxy_mobile_setup') and then enumerates actions concisely. No redundant information.

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

Completeness4/5

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

Given no annotations and no output schema, the description covers the main actions but omits details about return value and idempotency. It is fairly complete for a teardown tool with 6 parameters.

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

Parameters3/5

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

Schema coverage is 100%, so baseline is 3. The description adds minimal extra meaning over the schema; it only indirectly relates to android_target_id and stop_proxy. No new semantic details for ap_iface, ap_subnet, egress_iface, or block_quic.

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 explicitly states 'Reverse proxy_mobile_setup', clearly identifying it as the counterpart to the setup tool. It lists specific actions (deactivate Android target, stop listeners, emit script) that distinguish it from sibling tools like proxy_mobile_setup.

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

Usage Guidelines4/5

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

The phrase 'Reverse proxy_mobile_setup' strongly implies it should be used after setup. However, it does not explicitly state prerequisites or when not to use it, leaving some ambiguity about preconditions.

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

proxy_mock_responseC

Return a mock response for matched requests. Creates a mock rule.

ParametersJSON Schema

Name	Required	Description	Default
`body`	No	Response body
`method`	No	HTTP method to match (optional)
`status`	Yes	Response status code
`hostname`	No	Hostname to match (optional)
`priority`	No	Rule priority (default: 10, high priority)
`url_pattern`	No	URL regex pattern to match (optional)
`content_type`	No	Content-Type header	application/json

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, and the description does not disclose side effects such as rule activation, overwriting behavior, or lifecycle. Minimal details beyond the basic action.

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

Conciseness4/5

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

Two concise sentences with no waste. Could be slightly more structured (e.g., starting with the main action), but effective overall.

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

Completeness2/5

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

Given the complexity (7 parameters, no output schema, no annotations), the description is too sparse. Missing context about priority, rule matching behavior, and return values.

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

Parameters3/5

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

Schema description coverage is 100%, so the parameters are already well-documented. The description adds no additional semantic value beyond the schema.

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

Purpose4/5

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

The description clearly states it returns a mock response and creates a mock rule. It differentiates from sibling tools like proxy_add_rule, but could be more explicit about what 'mock rule' entails.

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?

No guidance on when to use this tool versus alternatives like proxy_add_rule or proxy_rewrite_url. The description lacks context for appropriate usage.

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

proxy_query_sessionA

Query indexed session exchanges by metadata (URL, hostname, method, status) with filters and pagination. Does NOT search body content — use proxy_search_session_bodies for that.

ParametersJSON Schema

Name	Required	Description	Default
`sort`	No		desc
`text`	No	Generic text filter
`limit`	No
`to_ts`	No	Unix ms upper-bound timestamp
`method`	No	HTTP method filter
`offset`	No
`from_ts`	No	Unix ms lower-bound timestamp
`session_id`	Yes	Session ID
`status_code`	No	HTTP response status code filter
`url_contains`	No	Filter by URL substring
`hostname_contains`	No	Filter by hostname substring

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool is for querying and does not search body content, but lacks details on authentication, rate limits, or potential side effects. It is adequate but not thorough.

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 extremely concise—two sentences with no wasted words. The key purpose is front-loaded, and the critical limitation (no body search) is stated immediately.

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?

The description covers the core purpose and differentiates from a key sibling, but with 11 parameters and no output schema, it omits return value details (e.g., format, pagination metadata) that would help an agent fully understand the tool's behavior.

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

Parameters3/5

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

Schema coverage is high (73%), so the baseline is 3. The description adds grouping of filters (URL, hostname, method, status) but does not provide additional meaning beyond what the schema already describes. Minor added value.

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 clearly states the tool queries session exchanges by metadata with filters and pagination, and explicitly distinguishes from sibling proxy_search_session_bodies by stating it does not search body content. This provides a specific verb and resource, differentiating it from related tools.

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

Usage Guidelines4/5

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

The description explicitly tells the agent when to use this tool vs proxy_search_session_bodies for body content search. However, it does not mention other possible alternatives or when not to use it, though the context is clear.

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

proxy_remove_host_upstreamA

Remove a per-host upstream proxy override.

ParametersJSON Schema

Name	Required	Description	Default
`hostname`	Yes	Hostname to remove override for

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description bears full responsibility. It conveys that the tool performs a removal (destructive), but it does not detail side effects, confirmation prompts, or any dependencies. Minimal transparency beyond core action.

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?

A single sentence that captures the tool's essence without any wasted words. It is front-loaded with the key action and resource.

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

Completeness5/5

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

For a simple tool with one required parameter and no output schema, the description is complete. It tells the agent exactly what the tool does and what input it needs.

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

Parameters3/5

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

Schema description coverage is 100% (single parameter with description). The tool description adds no additional meaning beyond restating the parameter's purpose. Baseline 3 applies.

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 clearly states the verb 'Remove' and the resource 'per-host upstream proxy override,' making it distinct from siblings like proxy_set_host_upstream (set) and proxy_clear_upstream (clear all).

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

Usage Guidelines3/5

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 versus alternatives, but the purpose is clear enough that an agent can infer it's for removing a specific host's override. No exclusions 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.

proxy_remove_ruleC

Delete an interception rule.

ParametersJSON Schema

Name	Required	Description	Default
`rule_id`	Yes	Rule ID to delete

TDQS

C2.9/5.0

Behavior1/5

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

With no annotations provided, the description carries full burden but only states 'Delete an interception rule.' It does not disclose that deletion is permanent, whether the rule must be disabled first, or any side effects. This is insufficient for an agent to understand the tool's behavior.

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

Conciseness4/5

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

The description is a single sentence, concise, and free of waste. However, it may be too brief to provide complete context, but for conciseness it is nearly optimal.

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

Completeness2/5

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

Given the simple tool with one parameter and no output schema, the description does not mention the result of deletion (e.g., success confirmation, effect on ongoing interceptions). It lacks completeness for an agent to fully understand the tool's behavior.

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

Parameters3/5

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

Schema description coverage is 100% with parameter 'rule_id' described as 'Rule ID to delete'. The tool description adds no additional semantic value; it simply restates the action. Baseline score of 3 is appropriate.

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 'Delete an interception rule' clearly states the verb 'Delete' and the resource 'interception rule'. It distinguishes from siblings like proxy_add_rule, proxy_disable_rule, and proxy_enable_rule by specifying a distinct action.

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?

No guidance on when to use this tool versus alternatives such as proxy_disable_rule. There is no mention of prerequisites, context, 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.

proxy_replay_sessionB

Replay selected requests from a recorded/imported session. Default mode is dry_run for safety.

ParametersJSON Schema

Name	Required	Description	Default
`mode`	No	dry_run previews replay plan; execute sends the requests	dry_run
`sort`	No		desc
`text`	No	Generic text filter
`limit`	No
`to_ts`	No	Unix ms upper-bound timestamp
`method`	No	HTTP method filter
`offset`	No
`from_ts`	No	Unix ms lower-bound timestamp
`session_id`	Yes	Session ID
`timeout_ms`	No	Per-request timeout in milliseconds
`status_code`	No	Response status code filter
`exchange_ids`	No	Explicit exchange IDs to replay (overrides query filters)
`url_contains`	No	Filter by URL substring
`target_base_url`	No	Optional base URL override (keeps original path+query)
`hostname_contains`	No	Filter by hostname substring

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It reveals that dry_run is safe and execute sends requests, but lacks details on permissions, reversibility, or side effects.

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 two sentences, front-loaded with core action (replay) and key default (dry_run). No extraneous words.

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

Completeness2/5

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

Despite 15 parameters, the description is very brief. It does not explain what dry_run returns, how filters interact, or expected output format. Lacks completeness for a complex tool.

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

Parameters3/5

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

Schema coverage is 80%, so the baseline is 3. The description adds no extra meaning to parameters beyond what the schema provides.

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

Purpose4/5

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

The description clearly states the action (replay) and resource (requests from a session). It is distinct from sibling tools like proxy_export_har, but does not explicitly differentiate itself.

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

Usage Guidelines3/5

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

The description implies usage with dry_run for safety, but offers no guidance on when to use this tool over alternatives like proxy_query_session or proxy_get_session_exchange.

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

proxy_rewrite_urlB

Rewrite request URLs matching a pattern. Creates a passthrough rule with body match-replace on the URL.

ParametersJSON Schema

Name	Required	Description
`hostname`	No	Limit to this hostname
`priority`	No	Rule priority (default: 50)
`replace_with`	Yes	Replacement string
`match_pattern`	Yes	Regex pattern to match in URLs

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It mentions creating a passthrough rule but omits side effects (e.g., rule priority interaction), permission requirements, or rate limits. The phrase 'body match-replace on the URL' is somewhat ambiguous.

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 extremely concise, consisting of two clear sentences with no unnecessary information. Every word contributes to understanding the core function.

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?

Given the absence of an output schema and the simplicity of the tool, the description is minimally adequate. However, it lacks details about return behavior, rule management implications, and edge cases, leaving gaps for a complete understanding.

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

Parameters3/5

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

The input schema has 100% coverage with descriptions for all 4 parameters. The description adds no additional parameter information beyond the schema, so a baseline score of 3 is appropriate.

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 clearly states the tool rewrites request URLs using a pattern, specifying the mechanism ('creates a passthrough rule with body match-replace on the URL') and distinguishes it from sibling tools like proxy_add_rule.

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?

No guidance is provided on when to use this tool versus alternatives such as proxy_add_rule or proxy_mock_response. There is no mention of preferred contexts or exclusion criteria.

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

proxy_search_session_bodiesA

Search inside HTTP request/response bodies stored in a persistent session. Decompresses and searches actual body content — useful for finding specific text, prices, API responses, error messages, etc. in recorded traffic. Returns context snippets around each match (like grep -C).

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes	Text to search for inside request/response bodies
`limit`	No	Max matching exchanges to return (default: 10, max: 100)
`method`	No	Pre-filter: HTTP method
`max_scan`	No	Max bodies to decompress and search (default: 200, max: 5000)
`search_in`	No	Which bodies to search (default: both)	both
`session_id`	Yes	Session ID
`status_code`	No	Pre-filter: HTTP status code
`url_contains`	No	Pre-filter: URL substring
`context_chars`	No	Characters of context around each match (default: 120)
`case_sensitive`	No	Case-sensitive search (default: false)
`hostname_contains`	No	Pre-filter: hostname substring
`content_type_contains`	No	Pre-filter: response content-type substring (e.g. 'html', 'json')

TDQS

A4.2/5.0

Behavior4/5

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

Without annotations, the description carries full burden. It discloses that the tool decompresses bodies, searches actual content, and returns context snippets like grep -C. This provides sufficient behavioral insight, though it does not cover error handling or performance.

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 two sentences, front-loaded with the core purpose and brief elaboration. Every sentence adds value without redundancy.

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

Completeness4/5

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

The description explains the core functionality and return format (context snippets). It does not document output schema, but given the complexity of 12 parameters, it covers the essentials well.

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

Parameters3/5

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

Schema description coverage is 100%, with clear parameter descriptions. The tool description adds context (decompression, grep-like output) but does not significantly enhance individual parameter understanding beyond what the schema provides.

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 clearly states the tool searches inside HTTP request/response bodies stored in a session. It specifies that it decompresses and searches actual body content, and lists use cases like finding text, prices, API responses. This distinguishes it from sibling tools like proxy_search_traffic.

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

Usage Guidelines4/5

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

The description provides clear context for when to use the tool (searching recorded traffic for specific text) and gives examples. However, it does not explicitly state when not to use it or mention alternatives.

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

proxy_search_trafficA

Full-text search across URLs, headers, and body previews of captured traffic.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Max results (default: 20)
`query`	Yes	Search string

TDQS

A3.5/5.0

Behavior3/5

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 discloses that the search covers URLs, headers, and body previews, implying partial content. However, it omits details like rate limits, result format, or behavior on empty results, which limits transparency.

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 a single, front-loaded sentence that conveys the core functionality efficiently. No extraneous information, making it highly concise.

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?

Given the tool's simplicity (2 parameters, no output schema) and the absence of annotations, the description is minimally complete. It identifies what is searched but does not describe return format or pagination, which might be needed for complex use cases.

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

Parameters3/5

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

Schema description coverage is 100% with both parameters having descriptions. The tool's description adds context about searching across specific traffic components, which supplements the schema. However, it does not provide deeper semantics beyond the schema's basic explanations.

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 clearly states the tool performs full-text search across URLs, headers, and body previews of captured traffic. It uses a specific verb and resource, and distinguishes itself from sibling tools like proxy_list_traffic (listing all) and proxy_search_session_bodies (more specific session search).

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?

No explicit guidance on when to use this tool versus alternatives like proxy_search_session_bodies or proxy_list_traffic. The description implies it is for general search, but does not mention exclusions or context, leaving the agent without clear direction.

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

proxy_session_recoverA

Rebuild session indexes from records after crash/corruption.

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	No	Recover only this session (default: recover all sessions)

TDQS

A4/5.0

Behavior3/5

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 implies a repair operation but does not disclose potential side effects (e.g., overwriting indexes) or whether it requires specific permissions. The description is adequate but could be more transparent.

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 a single, front-loaded sentence that conveys the purpose and context without any wasted words. It is concise and efficient.

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

Completeness4/5

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

For a simple recovery tool with one optional parameter and no output schema, the description provides enough context to understand its purpose and trigger. However, it could briefly explain what 'rebuild session indexes' entails for completeness.

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

Parameters3/5

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

Schema description coverage is 100% as the single parameter 'session_id' is well-documented in the input schema. The tool description does not add additional parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.

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 uses the specific verb 'Rebuild' with clear resource 'session indexes' and context 'after crash/corruption'. It clearly distinguishes from sibling tools like proxy_session_start and proxy_session_stop, which manage sessions rather than recover their indexes.

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

Usage Guidelines4/5

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

The description explicitly states the trigger condition ('after crash/corruption'), providing clear guidance on when to use. However, it doesn't mention when not to use or alternatives, though the context is sufficiently specific.

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

proxy_session_startB

Start persistent on-disk capture for the current proxy run.

ParametersJSON Schema

Name	Required	Description	Default
`max_disk_mb`	No	Session disk cap in MB
`storage_dir`	No	Custom storage directory
`session_name`	No	Optional session name
`capture_profile`	No	preview=body previews only, full=full request/response bodies	preview

TDQS

B3/5.0

Behavior2/5

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

No annotations provided, and the description does not disclose behavioral traits like whether it overwrites existing captures, if it requires authentication, or side effects. 'Persistent' is vague.

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

Conciseness3/5

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

The description is a single sentence, which is concise but may be too brief, lacking critical information. It is not verbose, but could be more informative.

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

Completeness2/5

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

Given 4 parameters, no annotations, and no output schema, the description is insufficient. It does not explain what 'persistent' means, how to stop the session, or what the return value is.

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

Parameters3/5

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

Schema coverage is 100%, so baseline is 3. The description adds no parameter context beyond schema descriptions, but that is acceptable given full coverage.

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 clearly states the tool starts a persistent on-disk capture for the current proxy run, using a specific verb and resource. It distinguishes from sibling tools like proxy_session_stop and proxy_session_status.

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?

No guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use, or that a session must be stopped with proxy_session_stop.

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

proxy_session_statusA

Get current persistent capture runtime status.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It adequately implies a read operation ('Get'), but lacks explicit statements about safety, side effects, or requirements (e.g., active session). The simplicity of a zero-parameter status tool makes this acceptable but not exemplary.

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?

Description is extremely concise at 6 words, single sentence, and front-loaded with the core action. Every word is necessary and no surplus content exists.

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

Completeness4/5

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

Given zero parameters, no output schema, and no annotations, the description is mostly complete. However, the term 'persistent capture' may need clarification for new users, but overall it covers the essential purpose.

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

Parameters4/5

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

No parameters exist in the input schema (100% coverage). According to guidelines, baseline is 4. The description adds no parameter info, but none is needed.

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?

Description clearly states 'Get current persistent capture runtime status' with a specific verb and resource. It distinguishes from siblings like proxy_status and proxy_transparent_status by specifying 'persistent capture runtime', making its purpose unique.

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?

No usage guidelines are provided. The description does not indicate when to use this tool over alternative status tools, such as proxy_status or proxy_session_status, nor does it mention any prerequisites or context.

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

proxy_session_stopA

Stop persistent on-disk capture and finalize the active session.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It states stop and finalize but does not disclose side effects (e.g., whether captured data is saved), prerequisites, or destructive nature. This is a significant gap.

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 a single, front-loaded sentence with no wasted words. It efficiently conveys the core action.

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?

Given no parameters and no output schema, the description is minimal but adequate for a simple stop command. However, it lacks details on the post-stop state and return value, leaving some uncertainty.

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

Parameters4/5

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

The input schema has zero parameters with 100% schema description coverage, so the description need not add parameter info. The baseline of 4 applies, and no additional detail is required.

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 clearly states the tool stops persistent on-disk capture and finalizes the active session. It uses a specific verb (stop) and resource (proxy session), and it distinguishes from siblings like proxy_session_start and proxy_session_status.

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

Usage Guidelines3/5

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

The description implies usage for stopping a session but provides no explicit guidance on when to use this tool versus alternatives, or any prerequisites. It is adequate but lacks directive context.

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

proxy_set_fingerprint_spoofA

Enable outgoing TLS + HTTP/2 fingerprint spoofing via impit (native TLS impersonation, no Docker required). Supports browser presets that select an impit target (rustls, matching real Chrome/Firefox).

ParametersJSON Schema

Name	Required	Description
`preset`	No	Browser preset name (e.g. 'chrome_131', 'chrome_136'). Use proxy_list_fingerprint_presets to see available options.
`user_agent`	No	User-Agent header to use with spoofed requests (overrides preset UA)
`host_patterns`	No	Only spoof requests to hostnames containing these substrings. Empty = spoof all HTTPS.
`disable_redirect`	No	Disable automatic redirect following
`insecure_skip_verify`	No	Skip TLS certificate verification

TDQS

A3.7/5.0

Behavior3/5

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 mentions native TLS impersonation and no Docker requirement, but does not disclose side effects, whether previous spoofing settings are overwritten, or any other behavioral implications beyond enabling spoofing.

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 exceptionally concise at two sentences, with no redundant information. Every phrase adds value, and it is front-loaded with the core functionality.

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?

Given the complexity (5 parameters, no output schema, no annotations) and the presence of many sibling proxy tools, the description provides adequate but not complete context. It does not mention return values, prerequisites (e.g., proxy must be running), or typical use cases, which could aid correct invocation.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description adds minimal value beyond the schema, merely restating that browser presets are supported. The schema already explains each parameter adequately, so the description does not enrich parameter understanding.

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 clearly states the tool enables TLS and HTTP/2 fingerprint spoofing via impit, with browser presets. It specifies the resource (fingerprint spoofing) and verb (enable), and distinguishes from siblings like proxy_set_ja3_spoof by mentioning HTTP/2 support.

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

Usage Guidelines3/5

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

The description implies usage for spoofing fingerprints but does not provide explicit when-to-use or when-not-to-use guidance. It references proxy_list_fingerprint_presets in the schema but fails to differentiate from alternative spoofing tools like proxy_set_ja3_spoof or prerequisites such as a running proxy.

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

proxy_set_host_upstreamA

Set a per-host upstream proxy override. Traffic to this hostname will use the specified proxy instead of the global one.

ParametersJSON Schema

Name	Required	Description
`hostname`	Yes	Hostname to override (e.g., api.example.com)
`no_proxy`	No	Hostnames to bypass this proxy
`proxy_url`	Yes	Upstream proxy URL for this host. If it has a username but no password, the password is filled in from PROXY_MCP_UPSTREAM_PASSWORD, but only when PROXY_MCP_UPSTREAM_HOST is also set and matches this URL's hostname. The response reports passwordSource: env \| url \| none.

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the core effect—traffic to the hostname uses the specified proxy instead of the global one—but omits details about persistence, idempotency, precedence over existing overrides, or the revert path.

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?

Two short sentences front-load the action and effect with no wasted words. The description is efficient and immediately understandable.

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?

As a simple setter, the description captures the essential behavior, but the absence of annotations and output schema leaves gaps: whether an existing override is replaced, whether the setting persists, and how to undo it are not addressed. The no_proxy parameter's behavioral role is also left to inference from the schema.

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

Parameters3/5

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

Schema description coverage is 100%, so all parameters are already documented in the schema. The description adds only the per-host context for hostname and does not elaborate on no_proxy or proxy_url semantics beyond what the schema provides.

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 uses a specific verb ('Set') and a precise resource ('per-host upstream proxy override'), immediately distinguishing it from global proxy configuration. The second sentence reinforces the scope by contrasting the per-host behavior with the global one.

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

Usage Guidelines4/5

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

The description clearly communicates when to use this tool: when a specific hostname should bypass the global upstream proxy. However, it does not explicitly name sibling alternatives such as proxy_set_upstream or proxy_remove_host_upstream, nor does it provide explicit when-not-to-use criteria.

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

proxy_set_ja3_spoofA

Legacy: enable fingerprint spoofing (deprecated, use proxy_set_fingerprint_spoof with a preset). The ja3 parameter is accepted but ignored — the default Chrome preset is used.

ParametersJSON Schema

Name	Required	Description
`ja3`	Yes	JA3 fingerprint string (ignored — use proxy_set_fingerprint_spoof with a preset instead)
`user_agent`	No	User-Agent header to use with spoofed requests
`host_patterns`	No	Only spoof requests to hostnames containing these substrings. Empty = spoof all HTTPS.

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It reveals that the ja3 parameter is ignored and that the default Chrome preset is used. This is key behavioral info. However, it does not disclose whether the spoofing applies immediately or requires a restart, which would be helpful but not critical for a legacy tool.

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?

Two sentences, zero waste. Every word earns its place. Front-loaded with 'Legacy' and deprecation, then the key behavioral note.

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

Completeness4/5

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

For a legacy tool with no output schema and clear deprecation, the description covers what it does, what to use instead, and the ignored parameter. It doesn't explain the effect on traffic or session state, but given its deprecated status, this is minimally sufficient.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description adds value by noting that the ja3 parameter is ignored and that the default Chrome preset is used, which goes beyond the schema's description ('ignored') by specifying the default behavior.

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?

Clearly states it enables fingerprint spoofing, marks itself as legacy, and directly names the replacement tool. The verb 'enable' and resource 'fingerprint spoofing' are specific, and it distinguishes from the sibling proxy_set_fingerprint_spoof.

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

Usage Guidelines5/5

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

Explicitly says it's deprecated and instructs to use proxy_set_fingerprint_spoof instead. Also clarifies that the ja3 parameter is ignored, so agents know not to rely on it. Provides both when-not and alternative.

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

proxy_set_upstreamB

Set a global upstream proxy for all outgoing traffic. Supports socks4://, socks5://, http://, https://, and pac+http:// URLs.

ParametersJSON Schema

Name	Required	Description	Default
`no_proxy`	No	Hostnames to bypass the upstream proxy
`proxy_url`	Yes	Upstream proxy URL (e.g., socks5://user:pass@host:port). If the URL has a username but no password, and the server has both PROXY_MCP_UPSTREAM_PASSWORD and PROXY_MCP_UPSTREAM_HOST set with the host matching this URL's hostname, the password is filled in from the environment so it need not appear in this call. Otherwise the URL is used as given; the response reports passwordSource: env \| url \| none.

TDQS

B3.4/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 behavioral disclosure burden. It says the proxy applies to all outgoing traffic and lists supported schemes, but does not disclose persistence, immediate effect, authentication expectations, or interaction with existing per-host proxy rules.

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?

One compact, front-loaded sentence states the action, scope, and accepted schemes without filler. Every part contributes to deciding whether and how to invoke the tool.

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?

Together with the rich parameter schema, the description is sufficient to construct a valid call for a global proxy. However, for a mutating tool with no output schema and no annotations, the missing side-effect and alternative-routing context leaves noticeable gaps.

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

Parameters4/5

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

The schema already documents both parameters thoroughly (100% coverage), so the baseline is 3. The description adds value by enumerating the accepted URL schemes (socks4://, socks5://, http://, https://, pac+http://), which goes beyond the schema's single example.

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

Purpose4/5

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

The description clearly states the action (set), the resource (global upstream proxy), and the scope (all outgoing traffic), plus the supported URL schemes. It is specific enough to stand apart from host-specific siblings like proxy_set_host_upstream, though it never explicitly contrasts itself with them.

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

Usage Guidelines3/5

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

The phrase 'global upstream proxy for all outgoing traffic' implies when this tool is appropriate and hints that it is not a per-host setting. However, there is no explicit when-not guidance or mention of alternatives such as proxy_set_host_upstream or proxy_clear_upstream.

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

proxy_startA

Start the HTTPS MITM proxy. Auto-generates a CA certificate. Returns port, URL, cert fingerprint, and setup instructions for the target device.

ParametersJSON Schema

Name	Required	Description	Default
`port`	No	Port to listen on (0 = random available port)
`max_disk_mb`	No	Per-session disk cap in MB (writes are dropped once exceeded)
`storage_dir`	No	Custom session storage directory
`session_name`	No	Optional name for the session when persistence is enabled
`capture_profile`	No	Capture profile for persisted sessions: preview (body previews) or full (full bodies)	preview
`persistence_enabled`	No	Enable persistent on-disk session capture (default: false)

TDQS

A3.7/5.0

Behavior3/5

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

No annotations are provided, so the description bears full burden. It mentions auto-generation of CA certificate and returns outputs but omits important behavioral traits: that the proxy runs until stopped, potential network interception, need for target device setup, or cleanup of temporary certificates. The disclosure is partial.

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 one efficient sentence that immediately states the action and lists the returned items. No redundant words; well front-loaded.

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?

Given the tool starts a long-running proxy with 6 parameters, no output schema, and many sibling tools (e.g., proxy_stop, proxy_start_transparent), the description lacks lifecycle context (how to stop, relationship to transparent mode) and does not clarify that a target device must be configured. Adequate for basic use but incomplete for nuanced decision-making.

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

Parameters3/5

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

Input schema has 100% description coverage, so baseline is 3. The description does not add extra meaning beyond the schema for any parameter. For example, it doesn't explain how 'capture_profile' or 'max_disk_mb' affect behavior beyond what schema says.

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 clearly states the tool starts an HTTPS MITM proxy with auto-generated CA certificate and lists key outputs (port, URL, cert fingerprint, setup instructions). It distinguishes from sibling tools like proxy_start_transparent by focusing on the standard proxy mode.

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

Usage Guidelines3/5

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

The description implies use when starting a standard MITM proxy but provides no explicit guidance on when to use it vs alternatives like proxy_start_transparent, nor any when-not-to-use conditions. No alternatives are mentioned.

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

proxy_start_transparentA

Start the transparent proxy listener. Receives iptables-redirected traffic (no CONNECT tunnels). Shares the same CA cert, rules, and traffic buffer as the explicit proxy. The explicit proxy must be started first.

ParametersJSON Schema

Name	Required	Description	Default
`port`	No	Port for the transparent listener (default: 8443)

TDQS

A4/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. Discloses shared resources (CA cert, rules, traffic buffer) and traffic type, but doesn't mention system changes (e.g., iptables modifications) or other behavioral traits.

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?

Three sentences, front-loaded with purpose, then traffic type and prerequisite. No redundant words.

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

Completeness4/5

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

Given low complexity (1 optional param, no output schema), description sufficiently covers purpose, traffic type, shared resources, and prerequisite. Could mention return value or stopping behavior for completeness.

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

Parameters3/5

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

Schema coverage is 100% with a description for the single parameter. Description adds no additional meaning beyond schema's 'Port for the transparent listener (default: 8443)'. Baseline 3 applies.

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?

Clearly states it starts the transparent proxy listener, distinguishes from explicit proxy by mentioning iptables-redirected traffic and no CONNECT tunnels.

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

Usage Guidelines4/5

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

Explicitly states prerequisite: 'The explicit proxy must be started first.' Implicitly differentiates from sibling proxy_start, but could be more explicit about when to choose this tool.

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

proxy_statusA

Get proxy running state, port, upstream config, rule count, and traffic count.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.6/5.0

Behavior3/5

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

Without annotations, the description must disclose behavioral traits. It describes a read-only operation and lists the information returned, which is adequate. However, it does not mention any side effects, authentication needs, or limitations beyond stating that it 'gets' data.

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 a single sentence of 13 words that directly states the tool's purpose and output without any superfluous information.

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

Completeness4/5

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

Given no output schema, the description lists the main fields returned (state, port, upstream config, rule count, traffic count), which is fairly complete. However, it lacks detail about the format or structure of the output.

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

Parameters3/5

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

The tool has no parameters, and schema coverage is 100%. The description adds value by naming the fields returned, but baseline is 3 given the trivial parameter set.

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 clearly states the verb 'Get' and the resource 'proxy status', and lists the specific pieces of information returned: running state, port, upstream config, rule count, and traffic count. This distinguishes it from sibling tools that perform actions like start/stop or add rules.

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?

No guidance is provided on when to use this tool versus alternatives. It merely describes what it does without any context about usage scenarios 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.

proxy_stopA

Stop the MITM proxy. Traffic history and CA certificate are retained.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It discloses that traffic history and CA certificate are retained, which is useful. However, it does not mention other effects like connection termination or proxy state change.

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?

Two concise sentences with no wasted words. Action verb first, then retention detail.

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

Completeness4/5

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

For a parameterless tool with no output schema, the description adequately covers what happens and what is preserved. Could optionally mention return value or side effects but not essential.

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

Parameters4/5

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

The input schema is empty (0 parameters), so baseline is 4. Description adds no parameter details but none are needed.

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

Purpose4/5

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

The description clearly states the action ('Stop the MITM proxy') and adds a retention note. It differentiates from proxy_start but does not explicitly distinguish from proxy_stop_transparent or proxy_deactivate_all.

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?

No guidance on when to use this tool versus alternatives like proxy_stop_transparent or proxy_deactivate_all. The description is purely functional.

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

proxy_stop_transparentA

Stop the transparent proxy listener.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.6/5.0

Behavior2/5

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

No annotations provided, so description must carry behavioral disclosure. Only states 'stop' with no details about side effects, preconditions, or safety. Insufficient for a mutation tool.

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?

Extremely concise, single sentence with no wasted words. Appropriate for a simple stop action.

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

Completeness4/5

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

For a tool with no parameters and no output schema, the description is mostly adequate, though lacking usage context.

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

Parameters4/5

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

Zero parameters; baseline score of 4 applies. Description does not need to add parameter meaning.

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?

Clearly states the verb 'Stop' and the resource 'transparent proxy listener', differentiating from siblings like proxy_stop and proxy_start_transparent.

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?

No guidance on when to use this tool versus alternatives such as proxy_stop or proxy_transparent_status. Lacks context for decision-making.

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

proxy_test_rule_matchA

Test which interception rules would match a request, with detailed per-field pass/fail diagnostics and effective winner by priority.

ParametersJSON Schema

Name	Required	Description	Default
`mode`	No	simulate: test a synthetic request, exchange: test an existing captured exchange	simulate
`request`	No	Synthetic request (required when mode=simulate)
`exchange_id`	No	Exchange ID from proxy_list_traffic (required when mode=exchange)
`limit_rules`	No	Optional limit on number of priority-sorted rules evaluated
`include_disabled`	No	Include disabled rules in diagnostics (default: true); disabled rules never win

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description must convey behavioral traits. It explains the diagnostic output but does not explicitly confirm that the tool is read-only or has no side effects. The absence of any warning or side-effect disclosure reduces transparency.

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 a single, well-structured sentence with no redundant words. It efficiently conveys purpose and output.

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

Completeness4/5

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

Given the 5 parameters, nested object, lack of output schema, and no annotations, the description covers the core functionality well. It mentions diagnostics and winner, but could briefly summarize the two modes (simulate vs exchange) for completeness.

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

Parameters3/5

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

Schema description coverage is 100% (all 5 parameters have descriptions). The tool description adds no additional parameter meaning beyond summarizing the overall behavior. Baseline score of 3 is appropriate.

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 clearly states the verb 'Test' and the resource 'interception rules', and specifies the output of 'detailed per-field pass/fail diagnostics and effective winner by priority'. This distinguishes it from sibling tools that list or modify rules.

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

Usage Guidelines3/5

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

The description implies a diagnostic use case but does not explicitly state when to use this tool versus alternatives like proxy_list_rules or proxy_update_rule. No exclusions or alternative references are provided.

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

proxy_transparent_statusA

Get status of the transparent proxy listener including port and traffic count.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

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

No annotations available, so description must stand alone. It discloses that the tool returns port and traffic count, indicating a read-only operation. No contradictions or hidden behaviors implied.

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?

Single sentence with no fluff, directly conveys purpose and key outputs. Perfectly concise.

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

Completeness5/5

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

Given no parameters and no output schema, the description adequately explains what the tool does and what it returns (port and traffic count). Sufficient for a simple status check.

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

Parameters4/5

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

Input schema has zero parameters, so description does not need to add parameter meaning. Baseline score reflects appropriate handling.

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?

Clearly states it retrieves status of the transparent proxy listener, specifying port and traffic count. Distinct from sibling tools like proxy_status or proxy_session_status by naming and specificity.

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

Usage Guidelines3/5

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

No explicit when-to-use or alternatives, but context implies it is for transparent proxy listener status. Siblings include similar status tools, so guidance would help but is not missing critical info.

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

proxy_update_ruleC

Modify an existing interception rule.

ParametersJSON Schema

Name	Required	Description
`handler`	No	New handler config
`matcher`	No	New matcher config
`rule_id`	Yes	Rule ID to update
`priority`	No	New priority
`description`	No	New description

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, so description must disclose behavior. Fails to clarify if update is partial or full replacement, what happens on invalid rule_id, or whether changes take effect immediately. Lacks side-effect details.

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

Conciseness2/5

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

At 4 words, the description is too brief for a tool with 5 parameters including nested objects. It sacrifices clarity for brevity; should at least mention updatable fields or behavior.

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

Completeness2/5

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

No output schema and no return value description. Missing guidance on success/failure signals, error conditions, or what the tool returns. Incomplete for a mutation tool in a complex domain.

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

Parameters3/5

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

Input schema covers 100% of parameters with descriptions, so baseline is 3. Description adds no additional meaning beyond the schema; it does not explain partial update semantics or required fields beyond rule_id.

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?

Description 'Modify an existing interception rule' uses a specific verb (modify) and resource (existing interception rule), clearly distinguishing from siblings like proxy_add_rule (create), proxy_remove_rule (delete), and proxy_enable_rule/proxy_disable_rule.

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?

No guidance on when to use this tool vs alternatives. Does not mention that proxy_add_rule should be used for new rules or proxy_remove_rule for deletion. Lacks context on prerequisites or best practices.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

3 tool updatesv3.4.0Aug 29, 2026

Changedproxy_mobile_setup1 field changed

changedInput schema / properties / upstream_proxy_url / description

Previous value: -"Optional upstream proxy URL (socks5://user:pass@host:port or http://...). Sets the global upstream for BOTH listeners."New value: +"Optional upstream proxy URL (socks5://user:pass@host:port or http://...). Sets the global upstream for BOTH listeners. If it has a username but no password, the password is filled in from PROXY_MCP_UPSTREAM_PASSWORD, but only when PROXY_MCP_UPSTREAM_HOST is also set and matches this URL's hostname. The response reports password_source: env | url | none."

Changedproxy_set_host_upstream1 field changed

changedInput schema / properties / proxy_url / description

Previous value: -"Upstream proxy URL for this host"New value: +"Upstream proxy URL for this host. If it has a username but no password, the password is filled in from PROXY_MCP_UPSTREAM_PASSWORD, but only when PROXY_MCP_UPSTREAM_HOST is also set and matches this URL's hostname. The response reports passwordSource: env | url | none."

Changedproxy_set_upstream1 field changed

changedInput schema / properties / proxy_url / description

Previous value: -"Upstream proxy URL (e.g., socks5://user:pass@host:port)"New value: +"Upstream proxy URL (e.g., socks5://user:pass@host:port). If the URL has a username but no password, and the server has both PROXY_MCP_UPSTREAM_PASSWORD and PROXY_MCP_UPSTREAM_HOST set with the host matching this URL's hostname, the password is filled in from the environment so it need not appear in this call. Otherwise the URL is used as given; the response reports passwordSource: env | url | none."

6 tool updatesv3.3.2May 17, 2026

Changedhumanizer_click1 field changed

changedInput schema / properties / target_id / description

Previous value: -"Browser target ID from interceptor_browser_launch"New value: +"Target ID from interceptor_browser_launch or interceptor_camoufox_launch"

Changedhumanizer_idle1 field changed

changedInput schema / properties / target_id / description

Previous value: -"Browser target ID from interceptor_browser_launch"New value: +"Target ID from interceptor_browser_launch or interceptor_camoufox_launch"

Changedhumanizer_move1 field changed

changedInput schema / properties / target_id / description

Previous value: -"Browser target ID from interceptor_browser_launch"New value: +"Target ID from interceptor_browser_launch or interceptor_camoufox_launch"

Changedhumanizer_scroll1 field changed

changedInput schema / properties / target_id / description

Previous value: -"Browser target ID from interceptor_browser_launch"New value: +"Target ID from interceptor_browser_launch or interceptor_camoufox_launch"

Changedhumanizer_type2 fields changed

changedInput schema / properties / delay_ms / description

Previous value: -"Extra delay per character in ms. Omit to let cloakbrowser pick its own humanized cadence."New value: +"Optional Playwright delay per character in ms."

changedInput schema / properties / target_id / description

Previous value: -"Browser target ID from interceptor_browser_launch"New value: +"Target ID from interceptor_browser_launch or interceptor_camoufox_launch"

Changedinterceptor_camoufox_launch2 fields changed

changedInput schema / properties / main_world_eval / description

Previous value: -"Allow `mw:`-prefixed evaluate() calls in the main world"New value: +"Allow explicit `world: 'main'` evaluate calls. On cloverlabs/FF150 this gates the call but does not create a separate realm."

changedInput schema / properties / os / description

Previous value: -"Fingerprint OS to emulate (defaults to camoufox random)"New value: +"Fingerprint OS to emulate (default: host OS; pass an array to let Camoufox choose from those OS families)"

10 tool updatesv3.3.1May 17, 2026

Changedinterceptor_browser_get_cookie1 field changed

changedInput schema / properties / target_id / description

Previous value: -"Target ID from interceptor_browser_launch"New value: +"Target ID from interceptor_browser_launch or interceptor_camoufox_launch"

Changedinterceptor_browser_get_network_field1 field changed

changedInput schema / properties / target_id / description

Previous value: -"Target ID from interceptor_browser_launch"New value: +"Target ID from interceptor_browser_launch or interceptor_camoufox_launch"

Changedinterceptor_browser_get_storage_value1 field changed

changedInput schema / properties / target_id / description

Previous value: -"Target ID from interceptor_browser_launch"New value: +"Target ID from interceptor_browser_launch or interceptor_camoufox_launch"

Changedinterceptor_browser_list_console1 field changed

changedInput schema / properties / target_id / description

Previous value: -"Target ID from interceptor_browser_launch"New value: +"Target ID from interceptor_browser_launch or interceptor_camoufox_launch"

Changedinterceptor_browser_list_cookies1 field changed

changedInput schema / properties / target_id / description

Previous value: -"Target ID from interceptor_browser_launch"New value: +"Target ID from interceptor_browser_launch or interceptor_camoufox_launch"

Changedinterceptor_browser_list_network_fields1 field changed

changedInput schema / properties / target_id / description

Previous value: -"Target ID from interceptor_browser_launch"New value: +"Target ID from interceptor_browser_launch or interceptor_camoufox_launch"

Changedinterceptor_browser_list_storage_keys1 field changed

changedInput schema / properties / target_id / description

Previous value: -"Target ID from interceptor_browser_launch"New value: +"Target ID from interceptor_browser_launch or interceptor_camoufox_launch"

Changedinterceptor_browser_navigate1 field changed

changedInput schema / properties / target_id / description

Previous value: -"Target ID from interceptor_browser_launch"New value: +"Target ID from interceptor_browser_launch or interceptor_camoufox_launch"

Changedinterceptor_browser_screenshot1 field changed

changedInput schema / properties / target_id / description

Previous value: -"Target ID from interceptor_browser_launch"New value: +"Target ID from interceptor_browser_launch or interceptor_camoufox_launch"

Changedinterceptor_browser_snapshot1 field changed

changedInput schema / properties / target_id / description

Previous value: -"Target ID from interceptor_browser_launch"New value: +"Target ID from interceptor_browser_launch or interceptor_camoufox_launch"

1 tool updatev3.3.0May 16, 2026

Changedinterceptor_browser_evaluate1 field changed

changedInput schema / properties / world / description

Previous value: -"`isolated` (default) or `main`. Main world only works on camoufox with `main_world_eval: true`."New value: +"`isolated` (default) or `main`. On current camoufox build (cloverlabs/FF150) both run in the page's main world — arg is accepted but has no observable effect."

3 tool updatesv3.2.0May 14, 2026
- Addedinterceptor_browser_add_script_tag
- Addedinterceptor_browser_evaluate
- Addedinterceptor_browser_inject_init_script
5 tool updatesv3.1.0May 12, 2026
- Changedinterceptor_browser_close1 field changed
  - changedInput schema / properties / target_id / description
```
Previous value: -"Target ID from interceptor_browser_launch"New value: +"Target ID from interceptor_browser_launch or interceptor_camoufox_launch"
```
- Addedinterceptor_camoufox_close
- Addedinterceptor_camoufox_info
- Addedinterceptor_camoufox_launch
- Addedinterceptor_camoufox_list

46 tool updatesv2.3.0May 5, 2026

Changedhumanizer_click10 fields changed

addedInput schema / properties / label

Added value: +{
+  "description": "Form-field label text (e.g. 'Email address')",
+  "type": "string"
+}

removedInput schema / properties / move_duration_ms

Removed value: -{
-  "default": 600,
-  "description": "Base duration for mouse movement (default: 600)",
-  "type": "number"
-}

addedInput schema / properties / name

Added value: +{
+  "description": "Accessible name; used with role (e.g. 'Sign in')",
+  "type": "string"
+}

addedInput schema / properties / role

Added value: +{
+  "description": "ARIA role (e.g. 'button', 'link', 'textbox')",
+  "type": "string"
+}

changedInput schema / properties / selector / description

Previous value: -"CSS selector to click (resolved via getBoundingClientRect)"New value: +"CSS or XPath selector (e.g. 'button.submit', '//button[@id=\"go\"]')"

changedInput schema / properties / target_id / description

Previous value: -"Chrome target ID from interceptor_chrome_launch"New value: +"Browser target ID from interceptor_browser_launch"

addedInput schema / properties / text

Added value: +{
+  "description": "Visible text to match (e.g. 'Accept cookies')",
+  "type": "string"
+}

addedInput schema / properties / timeout_ms

Added value: +{
+  "default": 15000,
+  "description": "Max ms to wait for locator to be visible + actionable (default: 15000)",
+  "type": "number"
+}

changedInput schema / properties / x / description

Previous value: -"X coordinate (used if selector is not provided)"New value: +"X coordinate fallback when no locator is given"

changedInput schema / properties / y / description

Previous value: -"Y coordinate (used if selector is not provided)"New value: +"Y coordinate fallback when no locator is given"

Changedhumanizer_idle1 field changed

changedInput schema / properties / target_id / description

Previous value: -"Chrome target ID from interceptor_chrome_launch"New value: +"Browser target ID from interceptor_browser_launch"

Changedhumanizer_move2 fields changed

removedInput schema / properties / duration_ms

Removed value: -{
-  "default": 600,
-  "description": "Base duration in ms before Fitts scaling (default: 600)",
-  "type": "number"
-}

changedInput schema / properties / target_id / description

Previous value: -"Chrome target ID from interceptor_chrome_launch"New value: +"Browser target ID from interceptor_browser_launch"

Changedhumanizer_scroll2 fields changed

removedInput schema / properties / duration_ms

Removed value: -{
-  "default": 400,
-  "description": "Total scroll duration in ms (default: 400)",
-  "type": "number"
-}

changedInput schema / properties / target_id / description

Previous value: -"Chrome target ID from interceptor_chrome_launch"New value: +"Browser target ID from interceptor_browser_launch"

Changedhumanizer_type4 fields changed

addedInput schema / properties / delay_ms

Added value: +{
+  "description": "Extra delay per character in ms. Omit to let cloakbrowser pick its own humanized cadence.",
+  "type": "number"
+}

removedInput schema / properties / error_rate

Removed value: -{
-  "default": 0,
-  "description": "Typo probability per character, 0-1 (default: 0)",
-  "type": "number"
-}

changedInput schema / properties / target_id / description

Previous value: -"Chrome target ID from interceptor_chrome_launch"New value: +"Browser target ID from interceptor_browser_launch"

removedInput schema / properties / wpm

Removed value: -{
-  "default": 40,
-  "description": "Typing speed in words per minute (default: 40)",
-  "type": "number"
-}

Addedinterceptor_browser_close
Addedinterceptor_browser_get_cookie
Addedinterceptor_browser_get_network_field
Addedinterceptor_browser_get_storage_value
Addedinterceptor_browser_launch
Addedinterceptor_browser_list_console
Addedinterceptor_browser_list_cookies
Addedinterceptor_browser_list_network_fields
Addedinterceptor_browser_list_storage_keys
Addedinterceptor_browser_navigate
Addedinterceptor_browser_screenshot
Addedinterceptor_browser_snapshot
Removedinterceptor_chrome_cdp_info
Removedinterceptor_chrome_close
Removedinterceptor_chrome_devtools_attach
Removedinterceptor_chrome_devtools_detach
Removedinterceptor_chrome_devtools_get_cookie
Removedinterceptor_chrome_devtools_get_network_field
Removedinterceptor_chrome_devtools_get_storage_value
Removedinterceptor_chrome_devtools_list_console
Removedinterceptor_chrome_devtools_list_cookies
Removedinterceptor_chrome_devtools_list_network
Removedinterceptor_chrome_devtools_list_network_fields
Removedinterceptor_chrome_devtools_list_storage_keys
Removedinterceptor_chrome_devtools_navigate
Removedinterceptor_chrome_devtools_pull_sidecar
Removedinterceptor_chrome_devtools_screenshot
Removedinterceptor_chrome_devtools_snapshot
Removedinterceptor_chrome_launch
Removedinterceptor_chrome_navigate

Changedinterceptor_status1 field changed

changedInput schema / properties / interceptor_id / description

Previous value: -"Interceptor ID (e.g., 'chrome', 'terminal', 'android-adb', 'android-frida', 'docker')"New value: +"Interceptor ID (e.g., 'browser', 'terminal', 'android-adb', 'android-frida', 'docker')"

Changedproxy_list_traffic1 field changed

addedInput schema / properties / source_filter

Added value: +{
+  "description": "Filter by traffic source: 'explicit' (proxy-configured) or 'transparent' (iptables-redirected)",
+  "enum": [
+    "explicit",
+    "transparent"
+  ],
+  "type": "string"
+}

Addedproxy_mobile_detect_iface
Addedproxy_mobile_setup
Addedproxy_mobile_teardown
Addedproxy_search_session_bodies

Changedproxy_set_fingerprint_spoof8 fields changed

removedInput schema / properties / disable_grease

Removed value: -{
-  "description": "Disable GREASE values in TLS ClientHello",
-  "type": "boolean"
-}

removedInput schema / properties / force_http1

Removed value: -{
-  "description": "Force HTTP/1.1 instead of HTTP/2",
-  "type": "boolean"
-}

removedInput schema / properties / header_order

Removed value: -{
-  "description": "Header order for outgoing requests (e.g. ['host','user-agent','accept',...])",
-  "items": {
-    "type": "string"
-  },
-  "type": "array"
-}

removedInput schema / properties / http2_fingerprint

Removed value: -{
-  "description": "HTTP/2 fingerprint (SETTINGS|WINDOW_UPDATE|PRIORITY frames). E.g. '1:65536;2:0;3:1000;4:6291456;6:262144|15663105|0:1:256:0,...'",
-  "type": "string"
-}

removedInput schema / properties / ja3

Removed value: -{
-  "description": "JA3 fingerprint string. Required if no preset is given.",
-  "type": "string"
-}

removedInput schema / properties / order_as_provided

Removed value: -{
-  "description": "Send headers in the exact order provided (default: true when header_order is set)",
-  "type": "boolean"
-}

changedInput schema / properties / preset / description

Previous value: -"Browser preset name (e.g. 'chrome_131', 'chrome_136'). Use proxy_list_fingerprint_presets to see available options. Individual params below override preset values."New value: +"Browser preset name (e.g. 'chrome_131', 'chrome_136'). Use proxy_list_fingerprint_presets to see available options."

changedInput schema / properties / user_agent / description

Previous value: -"User-Agent header to use with spoofed requests"New value: +"User-Agent header to use with spoofed requests (overrides preset UA)"

Changedproxy_set_ja3_spoof1 field changed

changedInput schema / properties / ja3 / description

Previous value: -"JA3 fingerprint string (ignored by curl-impersonate backend — use proxy_set_fingerprint_spoof with a preset instead)"New value: +"JA3 fingerprint string (ignored — use proxy_set_fingerprint_spoof with a preset instead)"

Addedproxy_start_transparent
Addedproxy_stop_transparent
Addedproxy_transparent_status

81 tool updatesv1.0.0Mar 15, 2026
- Addedhumanizer_click
- Addedhumanizer_idle
- Addedhumanizer_move
- Addedhumanizer_scroll
- Addedhumanizer_type
- Addedinterceptor_android_activate
- Addedinterceptor_android_deactivate
- Addedinterceptor_android_devices
- Addedinterceptor_android_setup
- Addedinterceptor_chrome_cdp_info
- Addedinterceptor_chrome_close
- Addedinterceptor_chrome_devtools_attach
- Addedinterceptor_chrome_devtools_detach
- Addedinterceptor_chrome_devtools_get_cookie
- Addedinterceptor_chrome_devtools_get_network_field
- Addedinterceptor_chrome_devtools_get_storage_value
- Addedinterceptor_chrome_devtools_list_console
- Addedinterceptor_chrome_devtools_list_cookies
- Addedinterceptor_chrome_devtools_list_network
- Addedinterceptor_chrome_devtools_list_network_fields
- Addedinterceptor_chrome_devtools_list_storage_keys
- Addedinterceptor_chrome_devtools_navigate
- Addedinterceptor_chrome_devtools_pull_sidecar
- Addedinterceptor_chrome_devtools_screenshot
- Addedinterceptor_chrome_devtools_snapshot
- Addedinterceptor_chrome_launch
- Addedinterceptor_chrome_navigate
- Addedinterceptor_deactivate_all
- Addedinterceptor_docker_attach
- Addedinterceptor_docker_detach
- Addedinterceptor_frida_apps
- Addedinterceptor_frida_attach
- Addedinterceptor_frida_detach
- Addedinterceptor_kill
- Addedinterceptor_list
- Addedinterceptor_spawn
- Addedinterceptor_status
- Addedproxy_add_rule
- Addedproxy_check_fingerprint_runtime
- Addedproxy_clear_ja3_spoof
- Addedproxy_clear_traffic
- Addedproxy_clear_upstream
- Addedproxy_delete_session
- Addedproxy_disable_rule
- Addedproxy_enable_rule
- Addedproxy_enable_server_tls_capture
- Addedproxy_export_har
- Addedproxy_get_ca_cert
- Addedproxy_get_exchange
- Addedproxy_get_session
- Addedproxy_get_session_exchange
- Addedproxy_get_session_handshakes
- Addedproxy_get_tls_config
- Addedproxy_get_tls_fingerprints
- Addedproxy_import_har
- Addedproxy_inject_headers
- Addedproxy_list_fingerprint_presets
- Addedproxy_list_rules
- Addedproxy_list_sessions
- Addedproxy_list_tls_fingerprints
- Addedproxy_list_traffic
- Addedproxy_mock_response
- Addedproxy_query_session
- Addedproxy_remove_host_upstream
- Addedproxy_remove_rule
- Addedproxy_replay_session
- Addedproxy_rewrite_url
- Addedproxy_search_traffic
- Addedproxy_session_recover
- Addedproxy_session_start
- Addedproxy_session_status
- Addedproxy_session_stop
- Addedproxy_set_fingerprint_spoof
- Addedproxy_set_host_upstream
- Addedproxy_set_ja3_spoof
- Addedproxy_set_upstream
- Addedproxy_start
- Addedproxy_status
- Addedproxy_stop
- Addedproxy_test_rule_match
- Addedproxy_update_rule

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

All tools have clearly distinct purposes, with detailed descriptions that differentiate even similar actions (e.g., interceptor_browser_evaluate vs interceptor_browser_inject_init_script). The grouping by prefixes (humanizer_, interceptor_, proxy_) further reduces ambiguity.

Naming Consistency5/5

Tool names follow a consistent snake_case pattern with clear category-action or category-subcategory-action structure (e.g., proxy_set_fingerprint_spoof, interceptor_android_activate). No mixed conventions are present.

Tool Count4/5

89 tools is large but justified by the server's broad scope as a comprehensive MITM proxy and interception platform covering multiple environments (browsers, Android, Docker, Frida). The count is slightly above typical ranges but each tool serves a specific purpose.

Completeness5/5

The tool set covers the entire lifecycle of network interception and manipulation: starting/stopping proxy, managing rules, capturing traffic, session handling, browser interaction, mobile & Docker interception, fingerprint spoofing, and more. No obvious gaps are present.

Maintenance

ActivityMaintained

ResponsivenessSlow

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Busymate DevToolsOAuth
dev.busymate
Capture, inspect & debug HTTPS traffic across iOS, Android, browsers & backends — 304 MCP tools.
Observability Developer Tools
2
simceptorOAuth
io.github.ayda212
AI-native mock API server with MCP. Create REST/SOAP mocks from Claude, Cursor, or Windsurf.
API Testing Testing & QA Tools
2
mcp
com.localtonet
Secure tunneling, reverse proxy and remote access for local applications.
Networking & Infrastructure Developer Tools
2
Webhook Studio A
com.webhook-studio
Keyless webhook endpoints: capture, wait, replay, forward, and generate types from real traffic.
API Testing Developer Tools
172

Related MCP Servers

Web Proxy MCP Server
mako10k
F
license
A
quality
D
maintenance
Intelligent HTTP/HTTPS proxy server with MCP integration for automated traffic monitoring, analysis, and browser setup.
Updated a year ago (2025-07-25 01:52 UTC)
22
-
Android Proxy MCP
Monitoring Web Scraping Developer Tools
zhizhuodemao
A
license
A
quality
F
maintenance
An MCP server that enables AI assistants to capture and analyze HTTP/HTTPS traffic from Android devices. It supports smart searching of network requests and provides tools for detailed traffic analysis via natural language.
Updated 7 months ago (2026-02-09 07:26 UTC)
11
223
MIT
httptoolkit-mcp
Testing & QA Tools Networking & Infrastructure
FL1NEE
A
license
A
quality
C
maintenance
MCP server for intercepting and mocking HTTP(S) traffic via a Mockttp proxy, with tools for Android emulator setup, traffic inspection, protobuf analysis, and rule-based manipulation.
Updated 3 months ago (2026-06-17 07:50 UTC)
35
108
MIT
mitmproxy-mcp
API Testing Browser Automation Web Scraping
u33pk
F
license
B
quality
B
maintenance
A lightweight MCP server built on mitmproxy that lets LLMs capture, inspect, replay, and modify HTTP traffic through a set of focused tools.
Updated 8 days ago (2026-08-29 05:48 UTC)
13
6
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/yfe404/proxy-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

proxy-mcp

Table of Contents

Setup

Quick install (Claude Code)

Prerequisites

From source (development)

Manual MCP configuration

HTTP Proxy Configuration

1) Start proxy and get endpoint

2) Browser setup (recommended: interceptor)

3) Browser setup (manual fallback)

4) CLI/process setup

5) Upstream proxy chaining

Keeping the upstream password out of the transcript

6) Validate and troubleshoot quickly

7) HAR import + replay

Mobile Capture (Transparent Proxy)

Prerequisites

First-time walkthrough

1. Flash + plug in the proxy-ap-card

2. Connect the target device to the laptop via USB

3. Run the setup tool

4. Run the emitted sudo script

5. Connect the phone to the proxy-ap WiFi

6. Start capturing

Subsequent sessions (phone already paired)

Upstream chaining

Verifying each step

Teardown

Troubleshooting

Without the proxy-ap-card

Limitations

Boundaries

TLS ClientHello Passthrough (browser via interceptor)

Built on stealth browsers + Playwright

Tools Reference

Lifecycle (4)

Transparent / Mobile Capture (6)

Upstream Proxy (4)

Interception Rules (7)

Traffic Capture (4)

Modification Shortcuts (3)

TLS Fingerprinting (9)

Interceptors (21)

Discovery (3)

Browser (3)

Camoufox (4) — anti-detect Firefox

Terminal / Process (2)

Android ADB (4)

Android Frida (3)

Docker (2)

Browser DevTools-equivalents (12)

Worlds and isolation — what your JS can and can't see

Sessions (14)

Humanizer — Playwright Input (5)

Resources

Usage Example

Architecture

Testing

Credits

Core Libraries

Vendored Frida Scripts

Available Tools

5. Connect the phone to the `proxy-ap` WiFi