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

With no annotations, the description carries the full burden and it does convey the core destructive behavior and the scope granularity. However, it does not state irreversibility, whether clearing is scoped to a session_id, or any effect on active proxy traffic, so transparency 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.

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

Every word earns its place: one sentence states the action and one sentence states the branching behavior. At roughly 18 words, it is optimally sized and front-loaded.

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

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

The tool is simple and has an output schema, so return values do not need explanation. Still, the description omits session_id semantics and any caution about the destructive nature of clearing, so completeness is only middling 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.

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

The description adds useful meaning to rule_type by clarifying that omission clears all four, which helps mitigate the schema's confusing 'rule_type=all' note. But the required session_id is never described in the description or schema, leaving the agent to infer which session's rules are being cleared.

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

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

The description states exactly what the tool does ('Clear active rules') and gives two operation modes: clearing one family by rule_type or clearing all four by omission. This is a specific verb+resource and is distinct from sibling tools like mitm_list_rules and the mitm_set_* tools.

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

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

The description gives clear usage direction: pass rule_type to clear one family, or omit it to clear all four. It does not name alternative tools, but none of the siblings perform clearing, so the usage context is reasonably complete.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'replay flows', without mentioning side effects (e.g., does it start a proxy? does it block? does it modify anything?), whether it is destructive, or what the return value looks like. For a tool that likely launches a long-running process, 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.

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

The description is a single, concise sentence that gets to the point, so it is not verbose. However, it lacks any structure (e.g., no separate lines for behavior, parameters, or examples) and is under-specified. It is appropriately short but does not earn its place beyond stating the core function.

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

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

Given the tool's complexity — a nested 'params' object with many modes, protocols, and optional fields — the description is far from complete. It does not explain how to set up modes, what the save_path does, or what the replay_kill_extra flag controls. Even though an output schema exists, the description does not mention the return value or how the tool interacts with the environment. For a tool with this many configuration options, the description is inadequate.

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

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

Schema description coverage is 0% — the description does not mention the 'params' object or any of its nested properties. While the schema itself has some field descriptions, the description adds no meaning beyond the schema. The agent must open the schema to understand even the basic mode parameter, and the description does not compensate for the low coverage at all.

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

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

The description clearly states the action (replay flows) and the resource (mitmdump), and specifies the two replay modes (client -C and server -S) from .mitm files. It distinguishes itself from sibling tools like mitmdump_start or mitm_export_flow by focusing on replay, but does not explicitly name alternatives, so it is not a perfect 5.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., that flows must already exist) or contrast with mitmdump_start or mitm_export_flow. An agent would have no idea whether to pick this over a sibling without additional context.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only says 'start', without mentioning that this launches a long-running, stateful session, may bind network ports, or should later be stopped via mitmdump_stop. 'Capture session' hints at statefulness, but the description does not explain side effects, resource usage, or lifecycle expectations.

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

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

The description is a single, well-ordered sentence of about 22 words. It front-loads the action and target, then lists optional capabilities without redundancy, filler, or repetition of the tool name.

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

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

This is a complex tool with nested mode objects, nine mode enums, mode-specific fields, and related lifecycle siblings. A single high-level sentence does not give an agent enough context about when to use it, what side effects to expect, or how to choose among modes. The presence of an output schema does not make up for the missing operational guidance.

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

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

The description provides broad semantic framing by mapping major capabilities to parameters: proxy modes to 'mode', output saving to 'save_path', filtering to 'filter_expression', and scripts to 'scripts'. However, given the reported 0% schema description coverage, it does not fully compensate by clarifying mode-specific requirements, flow_detail mapping, listen_host, or set_options.

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

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

The description starts with a specific verb ('Start') and names the exact resource ('headless mitmdump capture session'). It also enumerates the key capabilities — proxy modes, .mitm output saving, flow filtering, and scripts — which clearly distinguishes it from sibling tools like mitmweb_start or mitmdump_stop.

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

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

There is no guidance on when to use this tool versus alternatives such as mitmweb_start, mitm_execute_command, or mitmdump_stop. The description provides no conditions, prerequisites, or exclusions, so an agent must infer the appropriate context from the tool name and sibling list.

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

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

With no annotations, the description is responsible for flagging mutating behavior; it does state that the session is stopped and ports are released. However, it does not mention graceful-stop vs force-kill semantics, whether the call is reversible, or what happens if the session is already stopped.

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

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

One tight sentence with no filler; the action and resource are front-loaded, and 'release ports' is a valuable second clause. It earns its place.

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

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

Although an output schema exists and the input schema documents the session ID, the description alone lacks the lifecycle context needed to select and invoke it reliably: it doesn't identify where session_id comes from, distinguish it from mitmweb_stop, or mention optional stop behavior. For a destructive stop operation with no annotations, this is a meaningful gap.

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

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

The free-text description does not mention session_id, force, or timeout_seconds, and context reports 0% schema description coverage for parameters, so the description must compensate and does not. The only implied parameter is the session to stop, but mapping to the nested schema is left to the agent.

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

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

The description specifies a clear action ('Stop') and resource ('an active mitmproxy/mitmdump/mitmweb session'), and adds the effect 'release ports'. It is more specific than a bare name, but it doesn't explain how this relates to the sibling mitmweb_stop, which also appears to stop a mitmweb session.

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

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

There is no statement of when to use this tool rather than mitmdump_start, mitmweb_stop, or other session lifecycle alternatives. It gives no conditions, prerequisites, or exclusions, so an agent must infer the intended usage from the name.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It hints via examples that commands can clear views or kill flows, but it does not state destructive potential, allowlist failure behavior, session requirements, or output/error behavior.

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

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

A single front-loaded sentence with a direct verb, scope, and two illustrative examples. Every word earns its place and there is no filler.

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

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

For a generic command executor with nested parameters and no annotations, this is under-specified: an agent still needs to know where session_id comes from, how arguments bind, what happens for non-allowlisted commands, and what success/failure looks like.

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

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

With schema description coverage reported at 0% and no annotations, the description must compensate, but it only gives examples for 'command' and calls the session 'active'. It does not explain how to obtain or format session_id, what arguments mean, or how arguments map to a command.

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

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

The description names a clear verb ('execute'), a resource ('allowlisted command'), and a context ('active mitmweb session'), with concrete examples ('view.clear', 'flow.kill'). It does not explicitly contrast with sibling tools, so it stops short of full sibling differentiation.

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

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

It implies a prerequisite (an active mitmweb session) and an allowlist of commands, but gives no guidance on when to choose this tool over the many specialized mitm_* siblings. There is no when-not-to-use or alternative recommendation.

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

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

With no annotations provided, the description carries the burden and discloses a meaningful behavioral trait: 'secrets redacted (R4)'. The verb 'export' also implies a non-mutating read operation. It doesn't discuss permissions or side effects, but there is no annotation contradiction.

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

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

Two sentences with no filler; the action and format list come first, the source options second, and the redaction caveat last. Every sentence earns its place.

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

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

For a read-oriented export tool with an output schema, the description covers purpose, source modes, formats, and the key redaction behavior. Minor gaps such as the meaning of 'R4' and precedence when both session_id and flow_path are supplied prevent a 5.

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

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

The description maps session vs file sources to the session_id/flow_path parameters and enumerates format choices. However, it doesn't explain the required flow_id or preserve_original_ip, and schema description coverage is low, so it only partially compensates for the uncovered parameters.

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

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

The description opens with a specific verb and resource — "Export a captured flow to an external format" — and names the exact formats and the two source modes. This clearly distinguishes mitm_export_flow from the other mitm capture/manipulation siblings.

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

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

It gives concrete selection context: use it on an active session's dump or a standalone .mitm file, which maps to session_id versus flow_path. It doesn't explicitly list when-not-to-use or alternatives among siblings, so it stops short of a 5.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It names the filtering operation and source, but does not state whether this is read-only, whether it affects the active session, what happens when neither source is provided, or any side effects. The behavior remains largely implicit.

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

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

The description is a single sentence with no redundant wording. The core operation and the key distinguishing detail (source modes) are front-loaded, and every clause earns its place.

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

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

The tool has a nested parameter structureched and no annotations, so the description is the main guidance. It covers the essential filtering behavior and source selection, and an output schema exists, so return values need not be explained. Still, it lacks guidance on limits, source precedence, and how this differs from other flow-related siblings, making it adequate but not complete.

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

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

Schema description coverage is 0%, so the description must compensate. It does add meaning by explaining the expression family and the two sources, which helps interpret expression, flow_path, and session_id. However, it does not explain limit, mutual exclusivity, precedence, or default behavior when both sources are absent, leaving gaps.

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

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

The description starts with a specific verb and resource: 'Filter flows using mitmproxy FlowFilter expressions', and clarifies the source domains (dump file or active session). It is clear enough to distinguish this as a filtering operation, though it does not explicitly differentiate it from sibling tools like mitmweb_get_flows.

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

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

The description gives useful context about the two input sources: '.mitm dump file' or 'active session', which maps to flow_path and session_id. However, it does not state when to prefer this tool over sibling alternatives, nor any exclusions or preconditions like whether a session must be running.

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

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

No annotations are provided, so the description must carry the behavioral burden. It only says 'List the active rules' but does not mention that it requires a session_id, does not clarify whether it is read-only (though 'list' implies it), and does not describe failure behavior (e.g., if the session does not exist). The description is minimal and lacks transparency about its interaction with the session.

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

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

The description is a single sentence with no fluff, but it is too sparse to be effective. It is concise but omits critical context about the session parameter and return value, so the brevity is not a strength.

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

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

Given the tool has one required parameter and an output schema, the description should at least mention that the rules are scoped to session_id and what the output represents. It does neither, making the tool only partially understandable. The existence of an output schema does not compensate for the missing parameter explanation.

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

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

The schema has one required parameter (session_id) with 0% schema description coverage, and the description does not mention session_id at all. It fails to explain that the tool lists rules for a specific session, leaving the parameter's role ambiguous.

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

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

The description states a clear verb (List) and a specific resource (active map_remote/map_local/modify_headers/modify_body rules). This distinguishes it from sibling setter tools (mitm_set_map_remote, mitm_modify_headers, etc.) that modify rules rather than list them.

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

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

No explicit when-to-use guidance is given, but the tool name and listing nature clearly imply it should be used to inspect current rules before making changes. The description does not mention alternatives or exclusions, so it relies on implicit context.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals that the tool mutates payloads and applies DOTALL regex, but it does not disclose side effects, whether both directions are handled, how filtering selects items, reversibility, or any permissions/session requirements.

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

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

The description is a single front-loaded sentence with no filler; the primary verb and target are first, and the parenthetical adds the mitmproxy reference. It is as compact as possible while conveying the core action.

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

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

For a mutating tool with a nested rule object and a filter_expression parameter, the description is too thin. It lacks information about session context, scope of matching, and when to use payload modification, though the presence of an output schema reduces the need to document return values.

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

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

Schema description coverage is 0%, so the tool description should compensate, but it only restates regex substitution and DOTALL. It does not explain the rule object, pattern/replacement syntax, filter_expression semantics, or session_id usage, leaving parameter understanding to the nested schema alone.

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

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

The description opens with a specific operation ('Regex-substitute') and a specific resource ('matching request/response payloads'), and it names the mitmproxy primitive 'modify_body'. This is enough for an agent to distinguish it from payload-agnostic siblings like mitm_modify_headers or mitm_execute_command.

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

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

There is no guidance about when to choose this tool over alternatives, no exclusion criteria, and no mention of prerequisites such as an active proxy session. The intended context must be inferred entirely from the operation name.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It conveys a mutating effect, but does not disclose that SET replaces existing headers, REMOVE deletes matching headers and adds nothing back, or that filter_expression controls request/response direction; these details live in the schema rather than the tool description.

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

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

The description is a single front-loaded sentence with no filler. It names the action, target, and scope immediately, making every word useful.

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

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

An output schema and a rich nested input schema cover much of the invocation burden. The description is sufficient as a purpose statement but incomplete on its own for a mutation tool with no annotations, leaving operational caveats and usage context to be discovered from the schema.

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

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

The description gives no parameter-level guidance: it does not explain session_id, header_name, header_value, operation, or filter_expression. 'Set or remove' and 'matching' map only loosely onto the schema, and with schema description coverage reported at 0%, the description needed to compensate and did not.

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

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

The description names a concrete action ('set or remove'), a resource ('HTTP header'), and a scope ('matching requests/responses'), so an agent can understand what this tool does at a glance. It maps to the underlying mitmproxy option, but it does not explicitly distinguish itself from the sibling mitm_modify_body beyond the header/body distinction.

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

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

There is no guidance about when to use this tool versus alternatives such as mitm_modify_body or mitm_filter_flows, and no exclusions or prerequisites. The phrase 'matching requests/responses' hints at filtering, but does not tell the agent when this tool should or should not be chosen.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It explains the high-level effect and the path constraint, but does not disclose that this mutates mitmproxy rule state, requires an active session, or say whether existing matching rules are replaced or overridden.

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

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

Two sentences with no redundancy: the first states the action and target, the second adds the essential constraint. The most important operational rule is front-loaded.

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

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

The nested schema plus output schema cover the parameter details and return value shape, so the description need not repeat those. However, with no annotations and no mention of session-state requirements or rule-replacement behavior, the description is only minimally complete for a state-changing tool.

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

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

The tool description itself adds no parameter-level detail, but the nested schema thoroughly documents url_pattern, local_path, filter_expression, and the strict-path/allowlist preconditions. Although the context signal reports 0% top-level coverage, the schema does the semantic heavy lifting, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Serve') and clearly identifies the resource: requests matching a URL regex. It also specifies the source ('local file or directory'), distinguishing it from the sibling mitm_set_map_remote without ambiguity.

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

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

The description makes the core use case clear and states the critical allowlist precondition ('path MUST be inside allowed_mock_roots'), but it does not explicitly say when to prefer this over mitm_set_map_remote or other mock/modify tools. Usage guidance is therefore implied rather than explicit.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It conveys that the operation redirects requests and applies live, but it does not mention that this mutates mitmproxy state, how existing rules are affected, whether the rule persists, or what happens to matching requests during application.

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

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

The description is two short sentences with no filler. The core action is front-loaded first, and the live mitmweb context is relegated to the second sentence, making it easy to scan.

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

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

For a mutation tool with a nested rule object, a session identifier, and no annotations, the description is too thin. It omits the effect on existing rules, session binding, and relationship to sibling tools, so an agent may not fully understand the operational impact before invoking it.

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

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

Schema description coverage is reported as 0%, and the top-level description only captures url_pattern and replacement_url at a high level. It does not clarify session_id semantics or the optional filter_expression field, so the description does not compensate adequately for the low top-level coverage, even though nested properties have some schema documentation.

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

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

The description states a precise verb and resource: 'Redirect requests matching a URL regex to another remote URL' using mitmproxy map_remote. It also notes it is applied live over mitmweb, making the tool's function immediately identifiable and distinguishable from the sibling set_map_local tool.

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

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

There is no explicit guidance on when to use this tool versus alternatives like mitm_set_map_local or mitm_filter_flows. The phrase 'Applied live over mitmweb' gives some context, but it does not state prerequisites, exclusions, or when a different sibling would be more appropriate.

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

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

With no annotations, the description carries the behavioral burden. It does disclose a useful behavioral trait ('automatic secret redaction') and the kind of data returned, but it doesn't explicitly state that the operation is read-only, whether a session must be active, or any limits on payload size/content views.

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

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

A single, front-loaded sentence contains no filler or repetition, and every phrase adds information about scope, contents, and redaction behavior.

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

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

Given an output schema that documents return values and a nested input schema, the description is reasonably complete for selection, but it lacks guidance on when to use it and how the optional parts/content_view/redact options affect the result, which matters at 0% schema description coverage.

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

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

Schema description coverage is 0%, so the description must compensate. It partially does by linking 'headers, payloads' to flow content and 'content views' to the content_view parameter and 'secret redaction' to redact, but it doesn't explain required session_id/flow_id semantics or the parts/redact/content_view interplay in detail.

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

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

The description uses a specific verb ('Fetch') and a specific resource ('detailed inspection data for a single flow from mitmweb'), and lists included content (headers, payloads, content views). This clearly differentiates it from the sibling mitmweb_get_flows, which lists flows, by emphasizing a single flow.

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

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

The description implies use for inspecting one flow but never states when to reach for this tool versus alternatives such as mitmweb_get_flows, mitm_export_flow, or filter tools. It also provides no exclusion criteria or explicit precondition like needing an active mitmweb session.

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

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 signals a read-only retrieval and names the session requirement, but it does not disclose behavior such as pagination, default body omission, server-side filtering, error behavior, or what happens when the session is invalid. There is no contradiction, but the behavioral detail is thin.

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

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

The description is a single, front-loaded sentence with no filler. Every word adds information: the action, the resource, the protocol coverage, and the runtime context. This is an example of appropriately concise writing.

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

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

The tool has moderate complexity with a required session_id, pagination, a body toggle, and a server-side filter expression, but the description does not address any of these. Even with an output schema available, the description leaves out how to obtain a session_id, what defaults apply, and when to use related tools like mitmweb_get_flow_detail or mitm_filter_flows.

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

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

Schema description coverage is reported as 0%, and the tool description provides no parameter-level meaning for session_id, limit, offset, include_body, or filter_expression. The description does not compensate for the undocumented parameters, so an agent gets little help understanding how to invoke the tool correctly.

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

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

The description uses a specific verb ('Retrieve') and a clear resource ('captured flows'), and adds useful protocol scope (HTTP/WebSocket/TCP/UDP) plus the precondition 'from a running mitmweb session.' It is clear on its own but does not explicitly differentiate itself from sibling tools like mitmweb_get_flow_detail or mitm_filter_flows.

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

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

There is no when-to-use guidance, no mention of alternatives, and no exclusion criteria. The phrase 'from a running mitmweb session' weakly implies a precondition, but the description never tells the agent when to prefer this tool over mitmweb_get_flow_detail, mitm_filter_flows, or other siblings.

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

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. 'Start an interactive session' hints at a long-running side effect, but it does not mention whether the command blocks, returns immediately, requires cleanup, changes network settings, or must be paired with mitmweb_stop. The web UI/REST API note adds some context, but major behavioral gaps remain.

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

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

The description is a single, efficiently worded sentence with no filler. It front-loads the core action and key features. While it is too short for the tool's complexity, the conciseness itself is well handled.

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

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

Given the high complexity of the nested params schema, multiple modes, and many sibling tools, this description is incomplete. It omits when to use the tool, what the interactive session implies for lifecycle management, security-relevant options like web_password, and how this differs from mitmdump_start. An output schema exists, but that does not compensate for missing operational context.

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

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

The schema description coverage is 0%, and the description adds no parameter-level meaning. It does not mention the required nested mode array, scripts, web host/port, save path, or listen host. The input schema has detailed types and enums, but the description does not compensate for the lack of top-level parameter explanation.

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

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

The description uses a specific verb and resource: 'Start an interactive mitmweb proxy session'. It also highlights distinguishing features, 'web UI and REST API bridge enabled', which separates it from sibling tools like mitmdump_start and the stop/query tools.

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

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

No guidance is given on when to use this tool versus alternatives such as mitmdump_start, or when a session already exists and should be stopped. The description only implies 'start mitmweb' without any conditions, prerequisites, or exclusions.

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

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

No annotations are provided, so the description bears the full burden. It discloses that the tool terminates a session and releases listen/web ports, which is meaningful behavioral context. However, it does not mention shutdown behavior like graceful termination versus SIGKILL, cleanup of child processes, or impact on captured flows.

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

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

One concise sentence front-loads the primary action and includes a useful consequence. There is no filler or redundant restatement of the title.

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

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

The description is minimally sufficient for a straightforward stop operation: it names the resource, the action, and the port-releasing effect. However, with no annotations and no usage guidance, it leaves an agent to infer important context around forced termination, timeout behavior, and how this differs from stopping mitmdump sessions.

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

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

The description adds no parameter-level meaning. The schema visibly documents session_id, force, and timeout_seconds, but the context signal reports 0% schema description coverage; therefore the description should compensate and does not. An agent can infer that session_id refers to the session to stop, but force and timeout semantics are left entirely to the schema.

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

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

The description uses a specific verb and resource: 'Stop an active mitmweb session and release listen and web ports.' It clearly identifies what the tool acts on and adds a concrete consequence (releasing ports). It does not explicitly contrast with sibling tools like mitmdump_stop, so it misses the top score.

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

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

There is no guidance on when to choose this tool over alternatives such as mitmdump_stop or when a session should be stopped. 'Stop an active mitmweb session' only implies the basic use case; it does not state prerequisites, exclusions, or alternative routing.

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

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

With no annotations, the description carries the full disclosure burden. It conveys that the tool is a read operation by using 'List', and it specifies the session states included, but it leaves the term 'managed' ambiguous and does not clarify ordering, filtering, or potential side effects. More transparency would be helpful.

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

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

A single, front-loaded sentence communicates the action, resource, and scope with no fluff or redundancy. Every word earns its place.

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

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

For a parameterless listing tool with an output schema present, the description is nearly complete. The only notable gap is the vague 'managed' category and the lack of guidance on when to use this over closely related session/flow tools.

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

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

The tool has zero parameters, and the schema describes 100% of the parameter space, so there is a high baseline. The description does not need to add parameter details because there are none to explain.

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

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

The description opens with a clear verb, 'List', and a specific resource, 'mitmproxy sessions', and further qualifies the scope with 'active, stopped and managed'. This makes the purpose immediately distinguishable from sibling tools that start/stop sessions or list flows.

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

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

The description implies usage when a session listing is needed, but it provides no explicit when-to-use, when-not-to-use, or alternative guidance. It does not mention how it relates to sibling tools like session_status or mitmweb_get_flows.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not explicitly state that the operation is read-only, nor does it mention error handling, prerequisites, or effects. The verb 'Get' implies a read but does not disclose safety or side effects beyond that inference.

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

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

The description is a single, front-loaded sentence with no filler. It communicates the core action and resource efficiently, making it easy to parse.

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

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

The tool is simple with one parameter and an output schema, so return values are covered. However, the description does not explain when to use this tool relative to session_list or other session-related siblings, nor does it define what a 'session' is in this context. It is adequate but leaves contextual gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It only says 'by ID', which merely restates the parameter name session_id. It does not explain what a session ID is, how to obtain it, its format, or any validation, leaving the agent with minimal additional meaning.

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

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

The description uses the specific verb 'Get' with the resource 'detailed status and runtime parameters of a session' and qualifies by ID. It clearly differentiates from session_list (likely a list of sessions) and flow detail tools by focusing on session status, so an agent can distinguish it without opening the schema.

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

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

Usage is implied: if you have a session ID and need its detailed status, this is the tool. However, it does not explicitly state when not to use it or mention alternatives like session_list for listing sessions, so the agent must infer context from sibling names rather than receive direct guidance.

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