A
licenseA
qualityB
maintenanceEnables AI agents to interact with Charles Proxy for HTTP traffic analysis, supporting incremental harvest, checkpoint timelines, and rich filtering tools.
13
6
MIT
mitmproxy-mcp
by snapspecter
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@mitmproxy-mcpStart proxy, set scope to example.com, and get traffic summary."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
mitmproxy MCP Server
A Model Context Protocol (MCP) server that transforms mitmproxy into a powerful toolset for AI agents. This allows LLMs (like Claude, GPT-4, or local models) to inspect, modify, and replay HTTP/HTTPS traffic in real-time.
New in this build (the fun stuff)
This project has grown beyond simple capture + replay. You can now:
Search traffic quickly with filters by domain/method/body text.
Extract data from responses using JSONPath or CSS selectors.
Use session variables to grab tokens from one response and reuse them in later replays.
Run lightweight fuzzing against query params or JSON body fields for quick DAST checks.
Reconstruct API patterns and export an OpenAPI-style spec from captured traffic.
Detect auth patterns (Bearer/JWT/API key/session cookie/CSRF/OAuth hints).
Generate starter scraper code from real captured flows.
Related MCP server: mitmproxy-mcp
Why use this?
Standard "web search" or "fetch" tools are stateless and easily detected. mitmproxy-mcp provides:
Deep Debugging: The agent can inspect full request/response cycles (headers, payloads, cookies) to identify why a frontend is failing or why an API is returning a
4xx/500error.API Reverse Engineering: Let the LLM observe undocumented internal APIs, map out JSON schemas, and generate client libraries or documentation automatically.
Automated Security Testing: Perform DAST (Dynamic Application Security Testing) by allowing the agent to inject payloads into specific parameters and analyze the response.
Live Interception: Modify traffic on the fly: inject headers, mock responses for testing, or block tracking pixels to reduce noise.
Stealth Replay: Uses
curl-cffito mimic Chrome/Safari TLS fingerprints, bypassing basic anti-bot measures that standard Python libraries trigger.
Key Features
Lifecycle Control: Start and stop the mitmproxy instance directly from the LLM.
Deep Inspection: Capture full request/response cycles, including headers, bodies, and timing.
Traffic Search & Filtering: Scope by domain, then search flows by query/method so context stays clean.
Active Interception: Dynamic rules to inject headers, replace body content via regex, or block requests.
Stealth Replay: Re-execute flows using
curl-cffito impersonate modern browser TLS fingerprints (e.g., Chrome).Session-Aware Workflows: Extract dynamic values (like CSRF tokens) and re-inject them into replayed traffic.
Response Data Extraction: Pull structured values from HTML/JSON responses via CSS selectors and JSONPath.
API Discovery: Group similar endpoints, identify path/query params, and export OpenAPI JSON.
Security Recon Helpers: Detect common auth patterns and run targeted fuzz payloads.
Scraper Bootstrapping: Generate executable
curl-cffiautomation code from observed traffic.
Quickstart
Option 1: Using uvx (Recommended)
Add this to your MCP client configuration (e.g., Claude Desktop, Cursor, or AntiGravity):
{
"mcpServers": {
"mitmproxy-mcp": {
"command": "uvx",
"args": ["mitmproxy-mcp"]
}
}
}Option 2: From a Cloned Repository
If you want to run from a local clone (useful for development or testing unreleased changes):
git clone https://github.com/snapspecter/mitmproxy-mcp.gitThen add this to your MCP client configuration, replacing the path with your clone location:
{
"mcpServers": {
"mitmproxy-mcp": {
"type": "stdio",
"command": "uv",
"args": ["run", "--directory", "/path/to/mitmproxy-mcp", "mitmproxy-mcp"]
}
}
}Installation
Option 1: Global Install (with uv)
uv tool install mitmproxy-mcp
Option 2: Docker (Isolated Environment)
# Build and run
docker build -t mitmproxy-mcp .
docker run -p 8080:8080 mitmproxy-mcp
Option 3: Manual Pip Install
python -m venv venv
source venv/bin/activate
pip install mitmproxy-mcp
Available Tools
Lifecycle & Configuration
start_proxy(port=8080): Starts the mitmproxy server.stop_proxy(): Shuts down the proxy.set_scope(allowed_domains): Filters recorded traffic (e.g.,["api.github.com", "example.com"]).list_tools(): Returns all exposed MCP tools and input schemas.
Inspection
get_traffic_summary(limit=20): Returns a list of recent network flows.inspect_flow(flow_id): Provides full details and acurlequivalent for a specific flow.search_traffic(query, domain, method, limit=50): Filter captured traffic by keyword/domain/method.clear_traffic(): Clears persisted traffic history.
Modification & Interception
add_interception_rule(rule_id, action_type, ...):action_type:inject_header,replace_body, orblock.phase:requestorresponse.set_global_header(key, value): Injects a header into every request.remove_global_header(key): Removes a previously injected global header.list_rules(): Shows currently active interception rules.clear_rules(): Flushes all active interception rules.
Replay
replay_flow(flow_id, method, headers_json, body): Re-sends a request with modifications using browser-grade impersonation.
Extraction & Session Variables
extract_from_flow(flow_id, json_path=None, css_selector=None): Extract values from captured response bodies.set_session_variable(name, value): Manually set a session variable.extract_session_variable(name, flow_id, regex_pattern, group_index=1): Extract and save a variable from a response body.
Security & API Analysis
fuzz_endpoint(flow_id, target_param, param_type, payload_category, timeout=10.0): Replay with payload substitutions and report anomalies.get_api_patterns(domain=None, limit=50): Cluster captured traffic into endpoint patterns.export_openapi_spec(domain=None, limit=50): Produce an OpenAPI v3 JSON spec from captured traffic.detect_auth_pattern(flow_ids=None): Infer likely auth mechanisms from observed requests.
Code Generation
generate_scraper_code(flow_ids, target_framework="curl_cffi"): Generate starter scraper/automation code from captured flows.
Programmatic Usage
Note: These are JSON-RPC calls sent by the MCP Host (Client). You do not need to type these manually in the terminal.
Initialize the Proxy:
{"method": "tools/call", "params": {"name": "start_proxy", "arguments": {"port": 8080}}}Intercept & Block:
{"method": "tools/call", "params": {"name": "add_interception_rule", "arguments": {"rule_id": "block-ads", "action_type": "block", "url_pattern": ".*analytics.*"}}}Modify Response:
{"method": "tools/call", "params": {"name": "add_interception_rule", "arguments": {"rule_id": "mock-api", "action_type": "replace_body", "url_pattern": ".*user/profile.*", "action_value": "{\"name\": \"AI Agent\"}"}}}
Helpful Tips
Manage Context: Use
set_scopeimmediately. LLMs perform poorly when flooded with background OS telemetry.Browser Setup: Ensure your browser or application is configured to use the proxy (usually
localhost:8080) and has the mitmproxy CA certificates installed for HTTPS inspection.Stealth: The
replay_flowtool usescurl-cffispecifically to avoid being flagged as a bot by services that check TLS fingerprints.
Development
git clone [https://github.com/snapspecter/mitmproxy-mcp.git](https://github.com/snapspecter/mitmproxy-mcp.git)
cd mitmproxy-mcp
uv sync
uv run pytest
License: MIT
Available Tools
25 toolsadd_interception_ruleD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| rule_id | Yes | ||
| action_type | Yes | ||
| url_pattern | No | .* | |
| method | No | ||
| key | No | ||
| value | No | ||
| search_pattern | No | ||
| phase | No | request |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
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?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
clear_rulesD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
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?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
clear_trafficA
Clear all captured traffic from the database.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly indicates the destructive nature (clearing all traffic). For a parameterless tool with no annotations, it adequately discloses the core 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?
Single, clear sentence with no extraneous words. Perfectly concise.
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 and a clear destructive action, the description is mostly complete. Could mention irreversibility, but still sufficient for a simple tool.
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 (schema coverage 100%). Description adds no parameter info, which is appropriate since there are none.
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 ('Clear all captured traffic') and the resource ('database'). It distinguishes from sibling tools like clear_rules which clears rules, not 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 guidance on when to use this tool versus alternatives (e.g., search_traffic for inspection). No prerequisites or precautions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
detect_auth_patternD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| flow_ids | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
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?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_openapi_specA
Exports captured API traffic patterns to an OpenAPI v3 JSON specification. Args: domain: Filter traffic by domain limit: Max number of traffic flows to analyze. None = all flows.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | ||
| limit | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A3.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states the action but does not mention side effects, state changes, performance implications, or authorization needs. The behavioral transparency is minimal.
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 followed by a brief list of parameters. Every part is relevant and there is no fluff. It is well-structurally 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 tool's simplicity (2 optional params, output schema present), the description is mostly complete. It explains the output format and parameters. Minor gap: no mention of needing captured traffic or prerequisites, but overall 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 0%, so the description compensates well. It explains 'domain' as filtering by domain and 'limit' as max flows with 'None = all flows'. This adds meaningful context beyond the schema's type-only definition.
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 'exports' and the resource 'captured API traffic patterns' to an 'OpenAPI v3 JSON specification'. It is specific and distinguishes this tool from siblings like get_api_patterns or generate_scraper_code.
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 are no explicit when-to-use or when-not-to-use statements, and no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extract_from_flowB
Extract specific data from a flow's response body using JSONPath or CSS selectors. Args: flow_id: The ID of the captured flow json_path: A JSONPath expression to extract data from a JSON response css_selector: A CSS selector to extract data from an HTML/XML response
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| flow_id | Yes | ||
| json_path | No | ||
| css_selector | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
B3.2/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 behavior, but it omits details such as error handling, what happens if both selectors are provided, or format requirements for the flow's response body.
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 relatively concise, but the Args section could be more front-loaded; overall no wasted sentences.
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 presence of an output schema, omission of return value information is acceptable, but missing behavior details (e.g., selector priority, error conditions) reduce 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 0%, so the description adds meaning by explaining each parameter's purpose, but it simply restates the parameter names without deeper semantics.
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 extracts data from a flow's response body, naming specific selectors (JSONPath/CSS), which distinguishes it from siblings like inspect_flow or extract_session_variable.
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 inspect_flow or get_flow_schema; usage is merely implied by the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extract_session_variableA
Extract a value from a flow's response body using a regex and store it as a session variable. Args: name: Variable name (referenced as $name in replay_flow) flow_id: The ID of the flow to extract from regex_pattern: The regex pattern with capture groups group_index: Which regex capture group to extract (default: 1)
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| flow_id | Yes | ||
| regex_pattern | Yes | ||
| group_index | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 must convey behavioral traits. It covers the extraction and storage mechanism but omits important details such as error handling (e.g., regex mismatch), side effects (e.g., overwriting existing variables), and whether the tool is idempotent or has 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?
The description is concise and well-structured, using a clear docstring format with an Args section. Every sentence adds value without unnecessary verbosity.
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 tool's purpose and parameters adequately but lacks usage guidelines and behavioral details. Given that an output schema exists, return values need not be explained, but the omission of usage alternatives and error handling prevents a higher score.
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?
The description adds full parameter semantics beyond the schema's titles. Each argument (name, flow_id, regex_pattern, group_index) is explained with context, including that $name is used in replay_flow and that group_index defaults to 1. Schema description coverage is 0%, so the description compensates completely.
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 function: extracting a value from a flow's response body using regex and storing it as a session variable. This distinguishes it from siblings like set_session_variable (direct setting) and extract_from_flow (generic extraction).
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 regex extraction from flow responses but does not provide explicit guidance on when to use this tool versus alternatives like set_session_variable or extract_from_flow. No when-not-to-use conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fuzz_endpointA
Fuzz an endpoint by substituting a target parameter with a category of DAST payloads. Args: flow_id: The flow to replay as the base request. target_param: The name of the parameter to replace. param_type: The location of the parameter: 'query' or 'json_body'. payload_category: The category of payloads ('sqli', 'xss', 'path_traversal').
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| flow_id | Yes | ||
| target_param | Yes | ||
| param_type | Yes | ||
| payload_category | Yes | ||
| timeout | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 must carry the full burden. It explains the process (replay flow, substitute parameter, use payload categories) but does not disclose potential side effects, permission requirements, rate limits, or whether the original flow is modified. The presence of an output schema (not shown) partly compensates, but the description lacks depth on 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?
The description is succinct, using a single sentence to state the purpose followed by a clear list of arguments. Every sentence adds value, and the structure is front-loaded with the core 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 the presence of an output schema (true) and the tool's moderate complexity, the description provides enough context for basic use. It explains the core parameters and payload categories, but misses details like the effect of timeout and whether results are streamed or batched. Overall, it is nearly 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?
With 0% schema description coverage, the description adds significant meaning by explaining each required parameter and providing examples for param_type ('query' or 'json_body') and payload_category ('sqli', 'xss', 'path_traversal'). However, it omits the 'timeout' parameter, leaving its purpose unexplained.
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 ('Fuzz an endpoint'), the mechanism ('substituting a target parameter with a category of DAST payloads'), and the resource. It is specific and unambiguous, distinguishing the tool from its siblings which do not include fuzzing.
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 fuzzing endpoints but provides no explicit guidance on when to use or not use this tool, nor does it mention alternatives. The context of sibling tools shows no other fuzzing tool, so the implicit usage is acceptable but lacks precision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_scraper_codeB
Generate executable scraper/automation code from a comma-separated list of flow IDs. Args: flow_ids: Comma-separated list of flow IDs to include in the script. target_framework: The framework to generate code for (TODO: Add additional frameworks: Only 'curl_cffi' is currently supported).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| flow_ids | Yes | ||
| target_framework | No | curl_cffi |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
B3/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 mentions that only curl_cffi is supported and that it uses flow IDs, but does not disclose side effects, safety traits (e.g., read-only vs mutation), or return value behavior beyond what output schema might indicate.
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 fairly concise but includes a TODO comment that adds noise and may confuse agents. It uses an 'Args' section for clarity, but the TODO detracts from professionalism and focus.
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 2 parameters and an output schema, the description does not explain what the generated code looks like (e.g., format, language, or how to use it). The agent lacks sufficient context to understand the tool's full behavior and 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?
Schema description coverage is 0%, so the description must compensate. It explains flow_ids as a comma-separated list and target_framework as the framework (with a TODO note about future support). While this adds basic meaning, it lacks constraints, examples, or clarification on format (e.g., valid flow IDs).
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 generates executable scraper/automation code from flow IDs, using a specific verb and resource. It distinguishes from sibling tools that perform inspection, traffic management, or other actions, as no other sibling generates code.
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 is provided. There is no mention of prerequisites, when not to use it, or comparisons to similar tools like extract_from_flow or inspect_flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_api_patternsB
Cluster captured traffic into endpoint patterns. Args: domain: Filter traffic by domain limit: Max number of flows to analyze. None = all flows.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | ||
| limit | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
B3.3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description is minimal. It does not disclose whether the tool is read-only, modifies data, requires permissions, or has other side effects. The description relies on the name implying analysis, but lacks explicit behavioral details.
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 very concise: one sentence for purpose followed by two parameter explanations. No unnecessary 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two optional parameters and an output schema, the description is adequate but lacks details on output format or usage context. It does not mention the clustering algorithm or expected patterns.
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 description explains both parameters: 'domain' filters by domain and 'limit' sets max flows with None meaning all. While the schema coverage is 0%, the description adds meaning, though it could be more detailed (e.g., domain format, behavior when limit is exceeded).
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 clusters captured traffic into endpoint patterns, using a specific verb and resource. It distinguishes from siblings like search_traffic or get_traffic_summary, which are about searching or summarizing rather than clustering.
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, when not to use it, or comparison to similar tools like search_traffic or detect_auth_pattern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_flow_schemaC
Infer a simple schema from a flow's JSON response body.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| flow_id | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
C2.8/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It only states it infers a schema but does not disclose effects like whether it modifies data, requires flow existence, or handles non-JSON bodies. Lack of behavioral details.
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 with no fluff or repetition. Front-loaded with the core action and resource. Every word contributes.
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 output schema exists, return value is partly covered, but the description lacks completeness for task selection. It does not help the agent decide when to infer schema vs. using siblings like extract_from_flow or get_api_patterns. Missing context about required flow conditions.
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 coverage is 0%, meaning description does not explain the single parameter 'flow_id'. Although its purpose is implied by context, the description should explicitly state that flow_id identifies the flow whose response body is used. Fails to compensate for low coverage.
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 uses specific verb 'Infer' and resource 'schema from a flow's JSON response body', clearly stating the tool's function. It distinguishes from sibling tools like inspect_flow (inspects details) and extract_from_flow (extracts data) but could be more precise, e.g., 'generates a JSON schema'.
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 like inspect_flow or get_api_patterns. No mention of prerequisites, when to avoid, or context where inference is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_traffic_summaryD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
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?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
inspect_flowA
Get full details of a captured flow. Args: flow_id: The ID of the captured flow full_body: If True, return full request body instead of 2000-char preview
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| flow_id | Yes | ||
| full_body | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A3.6/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 such as side effects, permissions, or safety. It only describes the action without addressing potential impacts.
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: two sentences explaining purpose and parameters with no redundancy. The structure is 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?
Given the presence of an output schema (not shown), the description adequately covers purpose and key parameters. However, it could mention that it returns all details of a single flow, distinguishing from similar 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?
The description explains both parameters: flow_id (the ID) and full_body (controls full body vs. preview). Since schema coverage is 0%, this adds necessary meaning beyond the schema structure.
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 full details of a captured flow,' specifying the verb and resource. The name 'inspect_flow' and the context of sibling tools like 'inspect_flows' and 'extract_from_flow' make the tool's distinct purpose evident.
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 (e.g., 'inspect_flows' for listing, 'extract_from_flow' for specific parts). The description simply states what it does without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
inspect_flowsA
Batch inspect multiple flows in one call. Reduces context usage vs calling inspect_flow N times. Args: flow_ids: Comma-separated list of flow IDs to inspect fields: Comma-separated list of DB columns to select. e.g. "id,url,method,request_headers,request_body" to skip response data. Default: all columns. full_body: If True, return full request body instead of preview
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| flow_ids | Yes | ||
| fields | No | ||
| full_body | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description implies read-only operation (inspect). No side effects mentioned, but the tool is straightforward and non-destructive. Could add more context on limitations.
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?
Concise, front-loaded with key benefit, uses bullet points for arguments efficiently. 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?
Given 3 parameters, output schema exists, and no annotations, the description sufficiently covers all aspects needed for an agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 0%, but description explains all three parameters: flow_ids as comma-separated list, fields with example values, and full_body boolean. Adds significant meaning beyond schema names.
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 batches inspect multiple flows, reducing context usage. Explicitly distinguishes from sibling inspect_flow.
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 says when to use: for batching multiple flows to reduce context usage. Does not mention when not to use, but the primary use case is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_rulesD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
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?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_toolsA
List all available tools with their descriptions.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A3.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description correctly indicates the tool lists tools with descriptions, which is a read-only operation. However, with no annotations provided, the description carries full transparency burden and does not mention any potential requirements (e.g., authentication) or other behavioral traits, though the simplicity of the tool makes this acceptable.
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 concise and front-loaded, containing no unnecessary words. Every word serves a purpose, making it efficient for an agent to parse.
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 has no parameters and an output schema exists (to describe return values), the description is complete. It succinctly tells what the tool does without needing additional 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?
The tool has no parameters and schema coverage is 100% (trivially). Per guidelines, 0 parameters baseline is 4. The description does not need to add parameter information as none exist, so this score 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 function: listing all available tools and their descriptions. It uses a specific verb ('list') and resource ('all available tools'), which distinguishes it from sibling tools that perform actions like adding rules, clearing traffic, or searching.
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. Given the large set of sibling tools, explicit usage context (e.g., 'Use this to discover available tools before calling others') would be helpful but is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
load_traffic_fileA
Import flows from a HAR or mitmproxy flow file into the traffic database. After import, all traffic inspection tools work on the imported data. No proxy needs to be running. Args: file_path: Path to .har or .mitm/.flow file append: If True, keep existing traffic. If False (default), clear first. scope: Comma-separated list of domains to filter by during import. Only flows matching these domains are imported.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | ||
| append | No | ||
| scope | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides useful behavioral context: it explains the append parameter's effect on existing data (clear if false) and that no proxy is needed. It could be more transparent about failure modes or async behavior, but adequately discloses key aspects.
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 with four sentences plus a formatted Args list. It front-loads the purpose, is well-structured, and contains no extraneous 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 three parameters and an output schema (present but not shown), the description covers inputs well and ties to other tools. It lacks mention of error handling or file size limits, but is generally complete for a straightforward import tool.
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 0%, so the description compensates well by explaining file_path (supports .har, .mitm, .flow), append (keeps or clears existing traffic), and scope (comma-separated domain filter). This adds significant meaning beyond the schema's type-only definitions.
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 imports flows from HAR or mitmproxy files into the traffic database, with specific verb and resource. It distinguishes from siblings like clear_traffic and start_proxy by focusing on importing offline captured data.
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 mentions no proxy needs to be running and that imported data works with other inspection tools, implying offline usage. However, it does not explicitly state when to use this tool versus alternatives like start_proxy for live capture, leaving usage context somewhat implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
remove_global_headerD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
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?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
replay_flowC
Replay a captured flow, optionally with modified method, headers, or body. Supports session variable injection (e.g., $token) in headers and body.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| flow_id | Yes | ||
| method | No | ||
| headers_json | No | ||
| body | No | ||
| timeout | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 covers replay and session variable injection but omits details on idempotency, error states, authentication requirements, or whether the original flow is altered.
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 deliver the core purpose and a key feature without extra words. Front-loaded with the main action and optional modifications.
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 an output schema existing, the description lacks details on return values, success/failure indicators, and parameter specifics like timeout meaning or headers_json format. For a tool with 5 parameters, this is insufficient for confident 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?
Schema coverage is 0%, so description must compensate. It adds meaning to method, headers_json, and body by noting they can be modified and support session variable injection. However, it does not explain timeout or flow_id usage, nor the expected format of headers_json.
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 replays a captured flow with optional modifications, using a specific verb. It distinguishes from siblings like inspect_flow or extract_from_flow by focusing on re-execution. However, it does not explicitly differentiate from similar tools like extract_from_flow.
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 mentions optional modifications but provides no guidance on when to use this tool versus alternatives like inspect_flow or fuzz_endpoint. No when-not-to-use or prerequisite information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_trafficC
Search captured traffic using filters. Args: query: Keywords to search in URL or body domain: Filter by domain name method: Filter by HTTP method (GET, POST, etc.) limit: Max results to return
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| domain | No | ||
| method | No | ||
| limit | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 disclose behavioral traits. It states it searches with filters but does not clarify whether the operation is read-only, what the output format is, any rate limits, or if state is modified. The minimal description leaves significant gaps.
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, using a single sentence followed by a clean bullet list of parameters. Every element is purposeful, and the structure is easy to scan, though it lacks a return value note or usage example.
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 presence of an output schema (not shown), the description does not need to detail return values. However, it omits important contextual details such as pagination, filtering logic (AND/OR), and the specific fields available for search. For a tool with many siblings, more contextual guidance 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?
With 0% schema description coverage, the description adds value by explaining each parameter's role (e.g., 'query: Keywords to search in URL or body'). However, the explanations are shallow and do not cover constraints like value formats or allowed patterns for 'method'.
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 'Search' and the resource 'captured traffic', indicating it searches through captured traffic with filters. It distinguishes from siblings like 'get_traffic_summary' (summary) and 'inspect_flow(s)' (specific flow inspection), though it does not explicitly name alternatives.
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 (e.g., 'inspect_flows', 'get_traffic_summary'). There is no mention of appropriate contexts or when not to use it, leaving the agent to infer without support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
set_global_headerD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| value | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
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?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
set_scopeD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| allowed_domains | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
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?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
set_session_variableC
Manually set a session variable to use in replayed flows.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| value | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
C2.8/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses it's a manual write operation but lacks details on side effects (e.g., overwrite behavior), authorization needs, or rate limits. No annotations provided to compensate.
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?
Single sentence, no filler, but could be slightly expanded without losing conciseness.
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?
Lacks details on output (despite output schema existing), no behavioral context, and no parameter elaboration. Incomplete for a mutation tool with no annotations.
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?
Schema description coverage is 0% and the description adds no information about parameter format, constraints, or meaning beyond the schema's property names.
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 (set), resource (session variable), and context (in replayed flows), distinguishing it from sibling tools like extract_session_variable.
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; only implies usage in replayed flows, but doesn't specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
start_proxyD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| port | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
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?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stop_proxyD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
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?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
C2/5.0
Disambiguation2/5
Many tools have empty descriptions (e.g., add_interception_rule, clear_rules, detect_auth_pattern) or similar purposes (extract_from_flow vs extract_session_variable, set_global_header vs remove_global_header), making it hard to distinguish their roles. The overlap and lack of clarity cause confusion.
Naming Consistency2/5
Naming is inconsistent: some use verb_noun snake_case (add_interception_rule, clear_traffic), others use get_* (get_api_patterns, get_flow_schema), and some are imperative (start_proxy, stop_proxy). The mix of patterns and missing descriptions for several tools reduces predictability.
Tool Count3/5
25 tools is on the high side for a proxy/interception tool. While the domain can support many utilities, several tools seem redundant or have empty descriptions, making the count feel inflated without clear value.
Completeness2/5
The tool set covers capture, replay, and rule management but lacks essential features like interactive rule modification, live traffic modification, and individual rule removal. Security testing is partial (only fuzz_endpoint). Gaps in rule lifecycle and real-time interception are notable.
Maintenance
ActivityInactive
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Debug webhooks from your AI agent: inspect and replay captured webhooks on localhost.
Anonymous webhook capture, inspection, waiting, and response configuration for AI agents.
AI-callable tools for API mocking, testing, monitoring, security, and automation.
Give your AI agents the tools to build, manage, and run automation workflows.
Related MCP Servers
- FlicenseBqualityBmaintenanceA lightweight MCP server built on mitmproxy that lets LLMs capture, inspect, replay, and modify HTTP traffic through a set of focused tools.136
- AlicenseNot gradedqualityDmaintenanceAn MCP server that enables AI agents to intercept, inspect, and modify HTTP traffic, with tools for searching, filtering, and managing captured requests and interceptors.107MIT
- FlicenseAqualityAmaintenanceRuns a local HTTPS MITM proxy to intercept and mock network traffic from Android devices at the network level, enabling AI agents to register JSON transform rules and static responses without modifying app source code.2120
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/snapspecter/mitmproxy-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server