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

Annotations already establish idempotency, non-destructiveness, and that this is not a pure read. The description adds genuinely useful behavioral context beyond that: it returns the structured explanation plus new findings, and it re-runs even when a cached result exists unless refresh is false, explaining the caching semantics directly.

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?

Three tightly written sentences with the core purpose front-loaded, followed by return behavior and the caching nuance. Every sentence carries distinct information and there is no padding.

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

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

With full schema coverage, annotations covering the safety profile, and no output schema, the description is nearly complete for a two-parameter tool. It could note more explicitly that analysis may persist new findings, but overall an agent has what it needs to call this correctly.

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 100%, so the baseline is 3. The sentence 'Re-runs even if cached unless refresh is false' corroborates the schema's description of refresh but adds no syntax or format detail beyond it, and the provenance of request_id is also documented in 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?

States a specific verb (run the analysis pipeline) and resource (a single captured request), and enumerates the analysis types (linting, schema drift, privacy, performance), which makes its scope concrete. It does not, however, differentiate itself from likely alternatives such as rescan_findings or run_ai_workflow.

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 phrase 'on a single captured request' implies scope, and the refresh note hints at re-run scenarios, but there is no explicit statement of when to use this tool versus rescan_findings, run_ai_workflow, or get_request. Usage is implied rather than guided.

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?

Annotations already declare idempotent, non-destructive, non-read-only state, so the safety profile is covered. The description adds the crucial behavioral fact beyond annotations: this is a persistent activation that alters how later captures and replays behave. It doesn't say whether a prior environment is replaced or how activation is undone.

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 tight sentences, front-loaded with the effect and followed by the discovery hint. 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 one-parameter state toggle with full schema coverage and no output schema, this is nearly complete. The one omission is how the activation is cleared or replaced, which an agent might need, but no detach sibling exists to reference.

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

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

Schema coverage is 100%, and the single id parameter is fully documented there. The description only reinforces the source of the id via list_environments, adding little beyond the schema, so baseline 3 applies.

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?

States a specific verb (activate) on a specific resource (environment) and explains the effect: subsequent captures and replays resolve variables against it. This clearly differentiates it from the discovery sibling list_environments, which is named outright.

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?

Gives the operative context (use before captures/replays that need variable resolution) and routes discovery to list_environments. It lacks explicit when-not guidance or a way to detach/reset, 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?

Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=true, so the safety profile is covered. The description still adds genuine context beyond the structured fields: that the wipe is irreversible and that clients typically intercept it with a confirmation prompt, which sets agent 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?

Three short sentences, front-loaded with the destructive action, then the irreversibility warning, then the confirmation note. No filler and nothing buried.

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

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

For a zero-parameter destructive tool with full annotation coverage and no output schema, the description covers the essentials: scope, irreversibility, and confirmation. It does not mention preconditions such as whether capture must be stopped first, which would be a small remaining 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 tool takes zero parameters, so per the rubric the baseline is 4. The description correctly conveys there is no filtering or scoping argument — the operation is always a full buffer wipe.

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?

States a specific verb and resource with explicit scope: 'Delete every captured traffic entry from the engine buffer.' An agent can distinguish this bulk-clear from siblings like delete_session or list_traffic without opening any 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 context is implied rather than stated — there is no explicit when-to-use or when-not-to-use guidance, and no named alternative for narrowing or selectively deleting traffic. The mention of client confirmation is about execution behavior, not tool selection.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description adds the non-obvious operational constraint that both sessions must be terminated first, which is genuine context beyond annotations. It stops short of saying what happens if the precondition is unmet or how large diffs are bounded.

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, zero filler: the action and return contents come first, the gating precondition second. 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?

With no output schema, the description carries the return-value burden and does so by enumerating the comparison categories. Combined with the stopped-session precondition and fully documented params, an agent knows enough to call it, though it lacks detail on ordering or result size.

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

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

Schema coverage is 100% and both parameters carry clear role descriptions ('Session being evaluated (newer / candidate)' vs 'Reference session'). The description's phrase 'against a baseline session' mirrors the schema without adding format or constraint detail, so the baseline 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?

Names a specific verb (diff/compare) and resource (sessions) and specifies the output shape: added/removed/changed requests, latency deltas, finding drift. No sibling tool performs session comparison, so an agent can route here unambiguously against get_session, list_sessions, or replay_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?

The description supplies a precondition ('Both sessions must be stopped') that implies usage, but it does not state when to reach for this vs alternatives like replay_session or get_session, nor any exclusions. Usage is inferable but not explicitly guided.

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?

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false), so the bar is lower. The description adds the conceptual scope of chaos effects, but says nothing about whether the rule takes effect immediately, persistence across sessions, required permissions, or duplicate-name behavior beyond what annotations imply.

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 short sentences, front-loaded and waste-free. The first sentence restates the title/name almost verbatim, which is mild redundancy, but the second earns its place by explaining the effect domain.

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 7-parameter mutation tool with no output schema and only 57% schema coverage, yet the description covers none of the practical concerns an agent needs: how url_pattern matches, whether the rule is active on creation, or whether name must be unique. It is under-specified for the tool's complexity.

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 57% and the description contributes no parameter-level detail whatsoever. The parameters lacking schema descriptions (name, enabled, url_pattern) are largely self-explanatory, so the baseline of 3 applies, but the description does not compensate for the coverage gap.

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 gives a specific verb and resource ('Create a chaos rule') and the second sentence clarifies the domain by enumerating the kinds of degradation chaos injects. It never distinguishes this tool from its obvious siblings (create_mock_rule, create_rewrite_rule, update_chaos_rule), so sibling differentiation is missing.

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 indication of prerequisites or ordering relative to toggle_chaos_rule/list_chaos_rules, and no named alternative. An agent must infer entirely from the tool name that this is the creation entry point.

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?

Annotations declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, so the agent knows this mutates state non-idempotently, and the description's 'before persisting' confirms a new artifact is written. It does not state that repeated calls create duplicate rules or describe what is returned, so it adds only modest context beyond the annotations.

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 tightly written sentences with the composite fetch-then-create behavior front-loaded and no wasted words. Efficient and easy to parse, though the 'Convenience:' prefix is slightly informal 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 state-creating tool with no output schema, the description covers the mechanism (fetch by id, scaffold from recorded response, apply overrides) but omits what the call returns and how duplicates/non-idempotency are handled. Adequate but with visible gaps for a mutation tool.

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

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

Schema coverage is 100%, so all four parameters are already documented in the schema. The description's note about 'optional overrides let the caller tweak fields' usefully frames why name/url_pattern/dynamic exist, but adds no syntax or default detail beyond what the schema provides, matching the baseline 3.

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 specific composite verb+resource: fetch a captured request by id and scaffold a mock rule from its recorded response. This is clearly richer than a plain 'create mock' and distinguishes it conceptually from siblings like create_mock_rule, but it never explicitly names that alternative, so an agent must still infer which to pick.

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 leading word 'Convenience' implies the use case (scaffolding a mock from an existing captured request rather than authoring one from scratch), which is implied guidance. However, it never states when-not to use it or names the alternative (create_mock_rule, or get_request followed by manual creation), leaving selection partly to inference.

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?

Annotations already declare readOnly=false, idempotent=false, destructive=false, so the write profile is covered. The description adds genuine context beyond that: the rule fires in two distinct interception paths and is persisted in the engine database, which tells the agent about scope and durability.

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?

Three sentences, front-loaded with purpose, then behavior, then return value. Nothing is redundant and each sentence carries distinct information.

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

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

With no output schema, the description usefully states that it returns the created rule with its assigned id, and it covers persistence and firing scope for a 9-parameter mutation tool. The only gap is the absence of any hint about where this sits relative to create_mock_from_request.

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 100% across all 9 parameters, so the schema already documents name, method, url_pattern, status_code, dynamic templating tokens, headers, and delay. The description adds no parameter-level detail, which is the correct baseline when the schema does the heavy lifting.

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 specific verb+resource ("Create a mock rule") and clarifies the runtime scope: the rule fires through both the capture proxy and the standalone mock server. It does not differentiate itself from the sibling create_mock_from_request, which is a plausible confusion point, so it falls short of a 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?

There is no when-to-use guidance and no mention of the alternative create_mock_from_request, which creates a mock from observed traffic versus this tool's manual rule definition. The behavioral scope hints at where the rule applies but gives the agent no routing criteria.

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?

Annotations already declare readOnly=false, destructive=false, and idempotent=false, so safety is covered. The description goes beyond them by disclosing the core behavioral trait: rewrites mutate live requests/responses (headers, body, status) and do not short-circuit the upstream call. It does not cover failure modes or return behavior, keeping it from a 5.

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, zero filler, with the core action front-loaded and the distinguishing behavioral constraint immediately following. 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 7-parameter mutation tool with no output schema and no enums, the description establishes purpose and the non-short-circuit behavior but omits what a created rule returns, ordering/precedence concerns, or how the required trio (name, match_url, action) drives behavior. Adequate but leaves real 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 coverage is 71%, so most parameters carry their own descriptions (value, action, target, match_url, match_method). The description adds no parameter-level detail such as match pattern syntax, action verb vocabulary, or how target and value interact, so it does not compensate for the undocumented remainder.

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?

Names a specific verb (Create) and resource (rewrite rule) and adds the distinguishing behavioral trait that rewrites mutate live traffic without short-circuiting upstream. This implicitly separates it from the mock/chaos rule creators, though no sibling is named explicitly.

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 phrase 'without short-circuiting the upstream call' implies the rewrite scenario versus a mock that would stub the response, but there is no explicit when-to-use, when-not, or named alternative. Usage is inferable rather than stated.

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?

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The word 'Permanently' reinforces the destructive nature but adds little beyond the annotations, and nothing is said about error behavior for missing ids or downstream effects on captured sessions.

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 short sentence, front-loaded with the verb and the irreversibility qualifier. Zero waste.

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 destructive single-param tool, the description plus annotations cover the essentials of what it does and that it is dangerous. However, no output schema and no mention of return value or failure modes, and no pointer to list_chaos_rules to find the id, leaves 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% with a single required numeric id parameter. The description notes the lookup is 'by id', which is the only semantic hint available, but gives no format, source, or how to obtain the id. Baseline for a bare required param with no schema docs.

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?

States a specific verb (delete) and resource (chaos rule) with the key qualifier 'permanently' and the lookup key 'by id'. It does not name sibling tools like toggle_chaos_rule or delete_rule_pack to distinguish the resource class, so it falls short of 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?

No guidance on when to use this versus reversible alternatives like toggle_chaos_rule, which merely disables a rule. An agent has no signal that deletion is irreversible and disable might be preferable. Only implied 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?

Annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false, so the safety profile is covered. The description adds useful context: permanence ('Permanently delete') and audit logging. It doesn't contradict annotations; 'permanently' aligns with destructive.

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 short sentences, front-loaded with the core action and scope. No unnecessary words; 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 simple deletion tool with full annotation coverage and no output schema, the description provides key behavioral context (permanence, audit log). Might benefit from mentioning idempotency or what happens if the rule doesn't exist, but it's largely 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 coverage is 100%, so the single parameter 'id' is fully documented in the schema. The description only mentions 'by id' without adding format, constraints, or examples. Baseline 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?

States a specific verb (delete) and resource (mock rule), with the required identifier (by id). This clearly distinguishes it from sibling tools like toggle_mock_rule or update_mock_rule.

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 you want to permanently remove a mock rule), but offers no explicit when-to-use guidance, no alternatives (e.g., toggle_mock_rule for disabling), and no prerequisites.

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?

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered by structured data. The description's only addition is 'Permanently', which reinforces irreversibility, but it omits auth requirements, error behavior for unknown ids, and side effects on active traffic.

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 short sentence with the verb, resource, and identifier front-loaded and no filler. Nothing wasted.

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?

A single-parameter delete tool whose safety semantics are fully covered by annotations and which needs no output schema. The description is sufficient for correct invocation, though a note on what happens to in-flight traffic would make it 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?

With one parameter at 0% schema description coverage, the description must carry the load. Saying 'by id' signals the id identifies the rule to remove, which is marginally helpful, but it adds no type, format, or sourcing information beyond the schema's bare 'number' property.

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 specific verb (delete) and resource (rewrite rule) plus the keying mechanism (by id), so an agent can distinguish it from delete_chaos_rule or delete_mock_rule by the named resource. It does not explicitly route against siblings such as toggle_rewrite_rule, so it stops short of a 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?

There is no statement of when to use this tool versus alternatives, no preconditions, and no warning about what deletion entails beyond the word 'permanently'. The agent gets no routing guidance other than the resource 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?

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds a genuinely non-obvious behavioral fact beyond annotations: deletion is not cascading and leaves the pack's previously added rules in place. It stops short of noting permissions or what happens if the pack id does not exist, so it falls just short of the top mark.

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 short sentences, zero padding, with the core action front-loaded and the important non-cascade caveat second. Every sentence earns its place and directly changes agent 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?

For a single-parameter destructive tool with full annotation coverage and no output schema, the description supplies the one thing an agent could not infer: that rules added by the pack survive the delete. Missing only minor edges (invalid id, permission requirements), which is a small gap given the annotation 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?

Only one parameter (id), and schema description coverage is 100% ("Rule pack id."). The description adds no format, source, or lookup hints beyond the schema, so the baseline 3 applies.

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?

States a specific verb and resource ("Remove a rule pack from the engine") and immediately differentiates itself from the individual delete_* tools (delete_chaos_rule, delete_mock_rule, delete_rewrite_rule) that live in the same sibling set. An agent can tell what this operates on and what it does not cover without opening any 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?

Explicitly names the alternative (the individual delete_* tools in the mutate tier) and the condition that selects it: uninstalling rules the pack already added. There is also an implicit contrast with install_rule_pack/import_rule_pack/export_rule_pack from the sibling list. Nothing about routing is left to inference.

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?

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds genuinely useful context beyond them: deletion is 'permanent' and captured requests persist in the buffer, which is non-obvious scope information an agent needs.

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 sentence, front-loaded with the action and resource, with the scoping caveat placed in a tight parenthetical. 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?

For a single-parameter destructive delete whose annotations cover the safety profile, the key missing piece an agent would want (what happens to associated traffic) is supplied. Only the absence of explicit usage routing keeps it from 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?

Schema description coverage is 100% with a single 'id' parameter, so the schema already carries the semantics. The description adds nothing about the id or its format, making 3 the correct baseline.

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 gives a specific verb (delete) and resource (session), and the parenthetical 'the requests themselves stay in the buffer' sharply distinguishes it from clear_traffic at the traffic level. It does not name a sibling explicitly, so it falls just short of the 5 bar.

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 when-to-use guidance, no mention of alternatives, and no stated prerequisites. The parenthetical clarifies the effect, not the conditions under which an agent should choose this tool over clear_traffic or the other delete_* 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?

Annotations already declare idempotentHint=true and destructiveHint=false, so safety is partly covered. The description adds real value beyond them: the effect is scoped (removed from default views, not deleted) and the action is reversible via restore_finding, which is exactly the behavioral context an agent needs before mutating state.

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

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

Two short, front-loaded sentences with zero filler. The primary effect comes first and the reversal note follows, which is the right ordering for a state-changing tool.

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

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

For a two-parameter mutation with no output schema and annotations covering the safety profile, the description supplies the key missing pieces: the semantic effect and reversibility. It is essentially complete, with only minor gaps around permission requirements or idempotency restatement.

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

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

Schema coverage is 100% and both parameters (id, reason) are documented there, including that reason is recorded in the audit trail. The description adds no syntax or format meaning beyond the schema, so the baseline of 3 applies.

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?

States a specific verb (mark as dismissed) and resource (finding), plus the concrete effect (stops appearing in default views). It explicitly names its counterpart sibling restore_finding, letting an agent distinguish it without opening a 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?

Implies when to use it and explicitly names restore_finding as the reversal path, which signals the paired alternative. It lacks explicit when-not conditions (e.g., permanent deletion vs dismissal), but the route to the sibling is clear.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful scope (exports the current rule configuration, produces a portable manifest usable by import_rule_pack), but says nothing about whether disabled rules are included, the serialized format, or size/limits.

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

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

Two sentences, zero filler, with the core action front-loaded and the downstream usage in the second sentence. Nothing repeats the name or schema.

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

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

For a zero-parameter, read-only tool with no output schema, the description covers what is exported and where the result is meant to go, implying the manifest is directly consumable by import_rule_pack. It does not describe the shape of the returned manifest, which is the main residual 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 tool takes no parameters, so per the rubric the baseline is 4. There is no parameter surface for the description to clarify or obscure.

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?

States a specific verb (Export) and resource (the current rule configuration as a portable pack manifest), and names the sibling import_rule_pack as the consumer. An agent can distinguish it from import_rule_pack, list_rule_packs, and install_rule_pack without opening any 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?

Clearly explains the situation that motivates the call: save it, share it, or move it to another machine via import_rule_pack. It does not explicitly exclude or contrast with siblings like list_rule_packs or delete_rule_pack, so it stops short of full when/when-not guidance.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds a genuinely non-obvious behavioral trait beyond the structured fields: only the public PEM is exposed and the private key never leaves the engine, which answers the main data-exposure question an agent would have about a CA tool.

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

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

Two sentences, front-loaded with the return value and followed by the one qualification that matters. Every clause earns its place and nothing is padded.

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?

No output schema exists, so the description carries the return-value burden, and it does specify the answer is an availability check on the CA root. It stops short of describing the shape of the response (e.g., whether the PEM itself is returned alongside the boolean), leaving a small ambiguity.

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 takes zero parameters, so there is no parameter semantics to explain and the baseline is 4. The description correctly avoids inventing inputs for a parameterless status call.

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?

States a specific verb+resource ('Return whether a local CA root certificate is available') and scopes it with the purpose ('for HTTPS interception'). It is clear on its own, but it does not distinguish itself from the nearest sibling, proxy_status, which an agent could easily confuse it with.

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: nothing says to call this before starting interception, in a troubleshooting flow, or instead of proxy_status. The 'for HTTPS interception' phrase hints at the domain but is not an invocation condition.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful cost context ('Cheap'), which implies faster/less data than list_findings. It doesn't describe return shape or how severity/category buckets are named, but with annotations carrying the safety burden a 3 is appropriate.

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 short sentences, front-loaded with what it returns and followed by the routing advice. Every clause earns its place; 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 zero-param, read-only aggregate tool with annotations covering the safety profile, the description gives the agent enough to call it correctly and to know it precedes list_findings. A slight gap remains because there's no output schema and the description doesn't hint at the shape of the returned counts, but it is otherwise 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?

There are zero parameters, which hits the baseline-4 rule. The description correctly implies no inputs are needed ('Return counts... grouped by severity and category' with no filtering mention), so nothing is misrepresented.

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?

States a specific verb and resource ('Return counts of current findings') and names the grouping dimensions (severity and category). This distinguishes it clearly from list_findings, which returns the findings themselves, so the agent can tell the two apart without opening either 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?

Explicitly routes the agent: 'use this before list_findings to triage'. It names the alternative tool (list_findings) and the condition (triage/aggregate overview) that selects it, which is exactly the when-and-which-alternative guidance the dimension asks for.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuine extra context beyond that: headers are 'full' while the body is 'redacted', which tells the agent what it will actually receive and that payload content is not exposed or exportable.

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 sentence, front-loaded with the verb and the key scoping fact (single, by id). Nothing extraneous; every phrase carries information.

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

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

There is no output schema, and the description compensates by stating exactly what is returned (full headers, redacted body). It omits edge behavior such as a missing/expired id, but is otherwise sufficient for a one-parameter read tool.

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

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

Schema description coverage is 100% with a single parameter already documented as the traffic entry id from list_traffic. The description adds only 'by id', so baseline 3 is correct.

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?

States a specific verb (Return) and resource (single captured request) with the retrieval key (by id), and 'single' implicitly contrasts with the sibling list/search tools. It does not explicitly name which sibling to use instead, so it falls short of a 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?

Usage is only implied: 'by id' suggests the id must come from a listing tool, and the schema echoes this ('Traffic entry id from list_traffic'). There is no explicit when/when-not guidance or mention of alternatives like analyze_request or replay_request.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds value by disclosing the return content (entries, attached baseline), but says nothing about auth needs, error behavior for missing ids, or output shape beyond a loose hint.

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 well-formed sentence with the resource and scope front-loaded and no filler. Every clause earns its place by describing the returned manifest.

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 simple read-only getter with full schema coverage, the description is nearly sufficient, and it compensates for the absent output schema by naming what the manifest contains. Minor gaps remain around failure/missing-id behavior, but nothing essential is missing.

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?

There is only one parameter and schema coverage is 100%; the schema already explains that 'id' is a 'Session id from list_sessions.' The description's 'by id' adds no syntax or format detail beyond that, so the baseline of 3 applies.

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?

States a specific verb and resource ('Return the manifest of a single session by id') and even enumerates the payload ('included entries and any attached baseline'). It implicitly distinguishes itself from list_sessions by scoping to a single session, though it doesn't name the sibling explicitly.

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: fetch the full manifest of one session once you have an id. There is no explicit when/when-not guidance and no mention of alternatives like list_sessions or compare_sessions, leaving the agent to infer the boundary.

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?

Annotations already declare readOnly=false, idempotent=false, and destructive=false, so the safety profile is covered. The description adds genuinely non-obvious state behavior: the import only registers the pack and does not activate it until a separate call. It stops short of 5 because it does not say what happens on re-importing a pack that already exists or whether existing rules are affected.

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

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

Two sentences, front-loaded with the action and followed by the critical state caveat. Every clause earns its place with no redundancy or 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?

No output schema exists, and for a single-parameter, non-destructive mutation the description covers the essential lifecycle fact (register, then install). The remaining gap is error/idempotency behavior on duplicate imports, which is minor given the annotations already flag idempotent=false.

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 one parameter at 100% schema coverage, the schema already carries the load via 'Pack manifest JSON object. Same shape produced by export_rule_pack.' The description names the bundle's logical contents (mocks, rewrites, redaction rules) but adds no format, encoding, or required-field detail beyond the schema, so the baseline 3 applies.

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?

States a specific verb+resource ('Import a rule pack bundle') and enumerates the bundle contents (mocks + rewrites + redaction rules), immediately distinguishing it from install_rule_pack, export_rule_pack, and delete_rule_pack. An agent can tell exactly what this tool does 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?

Explicitly establishes the two-step workflow by naming install_rule_pack as the required follow-up ('registered but not installed until install_rule_pack is called'), which is the core routing decision. It does not, however, state when to prefer importing a pack over creating rules individually, so it stops short of full when/when-not guidance.

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?

Annotations already declare readOnly=false, destructive=false, and idempotent=false. The description adds useful context beyond them by warning that installation persists potentially many rules at once, but it doesn't clarify reversibility, whether existing rules are replaced, or permission 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?

Two short sentences, front-loaded with the core action and scope, with the caution attached at the end. Minimal waste, though 'use with care' is somewhat imprecise.

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 single-parameter tool with no output schema, the description adequately covers action, scope, and the bulk-effect caveat. It stops short of describing side effects on existing state or the expected result, but is otherwise 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 coverage is 100% and the single id parameter is fully documented with a pointer to list_rule_packs, so the schema carries the burden. The description adds no further parameter detail, making the baseline 3 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?

States a specific verb (Install) and resource (rule pack), and the qualifier 'previously-imported' distinguishes it from the sibling import_rule_pack. An agent can tell what operation this performs and on what object.

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?

'Previously-imported' implies a precondition (import first), and 'use with care' suggests caution, but no explicit alternatives or when-not-to-use guidance is given despite siblings like import_rule_pack, list_rule_packs, and delete_rule_pack being available.

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?

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the bar is lower. The description adds domain context about what chaos rules do ('inject latency, errors, and partial failures') but says nothing about scope, ordering, or filtering of the returned list.

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 short sentences, with the action stated first and the domain gloss second. Nothing is wasted and it is properly 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?

For a no-param, read-only list tool with no output schema and annotations covering safety, the definition is nearly sufficient. It could note whether all rules or only active ones are returned, but nothing critical is missing.

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 takes zero parameters, which is the baseline-4 case; there is no parameter syntax for the description to explain. The empty schema is self-evident and the description does not need to compensate.

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?

States a specific verb+resource ('List chaos rules') and the second sentence clarifies what chaos rules represent, which is useful for a domain term. It does not explicitly differentiate itself from siblings like list_mock_rules or list_rewrite_rules, but the operation is unambiguous.

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

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

No guidance on when to invoke this versus list_mock_rules, list_rewrite_rules, or the create/toggle/update/delete chaos siblings. The description never states context of use or alternatives, leaving routing to the agent's inference from the name alone.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: variable keys are returned and secret-shaped values are redacted, which tells the agent what data will and will not be visible in the result.

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 short sentences, no filler, and the primary purpose (list environments + active one) is front-loaded before the data-handling caveat. 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?

With no output schema available, the description carries the burden of describing the response and does so adequately: it names the environments, the active indicator, variable keys, and redaction behavior. Minor gaps remain (ordering, whether the list can be empty), but nothing essential for correct invocation is missing.

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 takes zero parameters, so there is no per-parameter semantics to document and the baseline of 4 applies. The description correctly characterizes the single return payload (environments plus active flag, variable keys with redacted secrets).

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 specific verb and resource ("List configured environments") and adds the key distinguishing detail that it also reports which environment is active. An agent can differentiate it from attach_environment, though the sibling is never named explicitly, so this falls just short of the top band.

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 when-to-use statement, no prerequisites, and no mention of alternatives such as attach_environment. For a zero-parameter, read-only listing tool the intended usage is strongly implied, so it lands at the minimum-viable level rather than being absent.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the taxonomy of finding types, but says nothing about ordering, volume, pagination, or the dismissed-filter behavior beyond what the schema carries.

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 tight sentences with the purpose front-loaded and the filtering hint second. No filler or repetition.

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-only list tool with full schema coverage and clear annotations, the definition gives enough to invoke it correctly. It is slightly thin on how results relate to the summary/dismiss/rescan siblings.

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 100% and each parameter is documented with its allowed values, so the schema does the heavy lifting. The description only restates that severity/scope can narrow results, adding no new semantics.

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?

States a specific verb (List) and resource (engine findings) and enumerates the finding categories (privacy, schema, performance, lint), which helps an agent understand what it returns. It does not, however, differentiate itself from close siblings like get_findings_summary, rescan_findings, or dismiss_finding.

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?

'Use severity or scope to narrow' gives implied narrowing guidance, but the description never says when to choose this tool over get_findings_summary (aggregate) or rescan_findings (refresh). Usage context is only implied.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety profile is covered. The description adds useful domain context (rules fire via capture proxy or standalone mock server), but does not disclose return shape, ordering, or persistence details.

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 tight sentences, front-loaded with the action, and the second sentence earns its place by explaining the rules' execution context.

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 no-param read-only list tool with no output schema, the description covers what the tool returns conceptually and where rules apply; minor gap is absence of guidance on downstream actions (toggle/update/delete).

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?

Zero parameters, so per the rubric the baseline is 4; description correctly adds no parameter noise and doesn't need to.

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?

States a specific verb (List) and resource (mock rules), and the second sentence explains what a mock rule is and where it applies, distinguishing it from the sibling list_* tools (chaos, rewrite, environments, etc.).

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 by the 'List configured mock rules' phrasing and its place among list_*/toggle_*/create_mock_rule siblings, but the description doesn't explicitly say when to use this versus e.g. list_chaos_rules or how to follow up with toggle_mock_rule.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description goes beyond them by explaining the domain semantics of the pause state — requests await agent or human review before release to the upstream — which tells the agent why the items exist and that they are blocking live traffic, though it says nothing about blocking timeouts or what a listed item contains.

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 sentence with no filler, front-loaded with the verb and resource, and the state qualifier packed at the end. Nothing could be removed without losing information.

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

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

For a zero-param, read-only list tool this is nearly sufficient, but with no output schema the description does not hint at what a paused-breakpoint entry looks like or what identifier an agent would need to pass to release_breakpoint. Minor gap rather than a blocking one.

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 takes zero parameters, which is the baseline-4 case; there is nothing for the description to clarify. The schema has no properties to document.

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?

Names a specific verb (List) and resource (requests paused at a breakpoint) and clarifies the state being listed. However, it never names the sibling release_breakpoint, which is the natural follow-up action, so an agent must infer the relationship from the tool list alone.

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 only implied: the phrase 'awaiting agent or human review' suggests you call this to inspect pending holds, but there is no explicit when-to-use directive, no statement about what to do next, and no warning about when this is empty (e.g., breakpoints disabled).

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the agent knows it's a safe read operation with closed-world scope. The description adds valuable behavioral context: rewrite rules mutate live requests/responses (headers, body, status) without short-circuiting the upstream call. This clarifies the effect of the rules being listed, which is beyond the annotations and useful for understanding the domain.

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

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

Two sentences, front-loaded with purpose and then a crucial distinction. Every sentence earns its place: the first states what it does, the second explains the nature of rewrite rules. No waste.

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 zero parameters, no output schema, and annotations covering safety, the description is nearly complete. It lacks explicit return format details (e.g., what fields are returned), but since no output schema exists, the agent might benefit from knowing the shape of the list. However, for a simple list tool, the description is adequate. The omission of return structure is a minor 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?

There are zero parameters, so per the rubric baseline is 4. The description doesn't need to discuss parameters because there are none, and it correctly omits parameter details. No additional semantic value is needed.

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?

Specific verb+resource: 'List configured rewrite rules'. The description also clarifies what rewrite rules are and how they differ from mock rules by noting they mutate live traffic without short-circuiting. This distinguishes it from siblings like list_mock_rules and list_chaos_rules.

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

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

Implies usage as a listing tool, but does not explicitly state when to use it versus alternatives (e.g., list_mock_rules, list_chaos_rules) or any prerequisites/conditions. The description lacks 'when-to-use' guidance beyond the obvious list purpose.

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?

The annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered without description help. The description adds useful domain context (what a rule pack contains, and why one would exist), but says nothing about return shape, pagination, or whether uninstalled/remote packs are excluded. With annotations doing the heavy lifting, this is adequate but not rich.

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

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

Two sentences, front-loaded with the action and resource, followed by a compact definition of the domain concept. Every clause 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?

This is a simple, zero-parameter read tool with no output schema, so the description's burden is light. It explains the resource concept well enough for correct invocation, though it stops short of describing what the returned pack list looks like or how it relates to the install/export/delete siblings.

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 takes zero parameters and the schema is an empty object, so there is no parameter semantics to document. The baseline for a 0-parameter tool is 4, and nothing in the description contradicts 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 opens with a specific verb+resource ('List installed rule packs') and then defines the resource domain ('a versioned bundle of mocks/rewrites/redaction rules'), which meaningfully separates it from siblings like list_mock_rules or list_rewrite_rules. It never explicitly names an alternative tool, so it falls short of a 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?

Usage is implied by 'list installed rule packs' — an agent can infer it should call this when it needs the current set of packs before install/export/delete operations. However, there is no explicit when-to-use statement, no exclusion, and no routing to siblings such as install_rule_pack or export_rule_pack.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context about the resource itself (server-side execution in a goja VM, ability to mutate traffic), but says nothing about the tool's own behavior — ordering, what happens when no scripts are installed, or what is returned.

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 tight sentences, no filler, with the core action front-loaded. The second sentence is context rather than invocation guidance, but it earns its place by defining the resource the agent is listing.

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

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

For a zero-parameter list tool with no output schema, the description omits what each returned entry actually contains (script name, enabled state, scope/matchers) or whether results are ordered. Annotations cover safety and there are no params to document, so the gap is narrow but real.

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 takes zero parameters, so there is nothing for the description to disambiguate. The baseline for a parameterless tool is 4.

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?

States a specific verb and resource: 'List installed JS hook scripts.' The second sentence clarifies what a script actually is (server-side goja VM code that mutates requests/responses), which meaningfully disambiguates it from siblings like list_rewrite_rules and list_mock_rules. It does not explicitly contrast itself with those siblings, so it falls short of a 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?

No when-to-use, when-not-to-use, or alternative-tool guidance is given. The note that scripts 'mutate any request/response programmatically' hints at why one would care about scripts, but the agent is never told when to reach for this tool versus list_rewrite_rules, list_mock_rules, or list_chaos_rules.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful domain semantics about what a session is (a bookmarked traffic range for replay/sharing/diffing), but says nothing about ordering, completeness of the listing, or what identifying fields come back.

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 short sentences, front-loaded with the action and followed by the minimal definition needed to interpret the result. No filler or repetition.

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

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

For a zero-parameter, read-only list tool with no output schema, the description covers the essentials: what is listed and what a session represents. It stops short of describing the returned shape, but that is a minor gap given the simplicity of the operation.

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

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

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to disambiguate beyond confirming that the listing is unfiltered.

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?

States a specific verb and resource ('List named sessions') and then defines the domain object, which separates it from generic siblings like list_traffic. It doesn't explicitly contrast with get_session, delete_session, or compare_sessions, but the resource and its meaning are unambiguous.

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

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

There is no when-to-use guidance and no mention of alternatives such as get_session for details or compare_sessions for diffing. Usage is only implied by the verb 'List', leaving the agent to infer when this tool is the right choice.

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?

Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds a genuinely useful behavioral fact beyond the structured data: response bodies are redacted server-side before return, which tells the agent to expect truncated payloads. It stops short of describing ordering or what a result row contains.

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?

Three tight sentences, front-loaded with the core action, and each carries content. Minor overlap in re-listing the filter dimensions that the schema already enumerates, but nothing is padded or redundant at the sentence level.

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-only list tool with no output schema, the description covers scope, filter dimensions, pagination, and the redaction caveat, which is enough to invoke it correctly. Missing only ordering/default-sort behavior and a clear boundary against the overlapping 'search_traffic' sibling.

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

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

Schema coverage is 100%, so all five parameters are already documented with descriptions (substring match, 1-indexed page, capped page size, etc.). The description restates the filter dimensions but adds no syntax, defaults, or format detail beyond what the schema provides, so the baseline 3 applies.

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?

States a specific verb+resource ('List captured HTTP/HTTPS requests') that is unambiguous on its own. However, it never differentiates itself from the sibling 'search_traffic', which an agent could easily confuse with this tool given the overlapping subject matter.

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 explains what the filters do but gives no when-to-use guidance, no exclusions, and no routing to alternatives. With a sibling named 'search_traffic' in the same toolset, the absence of a 'use this for X vs. search_traffic for Y' clause is a real gap.

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?

Annotations declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, but the description adds the key underlying reason: 'Scanning records each suggestion in the engine,' which explains the non-read-only hint as a benign recording side effect rather than mutation. It also discloses the out-of-band install path, which the structured fields cannot convey.

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?

Purpose and scope are front-loaded in the first sentence, with the side effect and installation workflow following. The second and third sentences are dense but each carries real information; 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?

There is no output schema, but the description specifies the return ('only the redaction-kind suggestions') and the recording side effect, plus the install follow-up path. An agent has enough to call it and understand consequences, though return-shape specifics are minimal.

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 100% and the single `limit` parameter is fully documented in the schema (including its server-side default). The description adds no parameter detail, so the baseline of 3 applies.

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 specific verb+resource (scan captured traffic for PII/secret patterns, propose redaction rules) and scopes the output precisely: only redaction-kind suggestions not already covered by existing rules. This cleanly separates it from siblings like list_findings or rescan_findings.

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 explains the intended workflow and, critically, that installing a suggested rule is NOT exposed over MCP, naming two alternatives (accept in the app's suggestions view, or `proxykit redaction add --path <key>`). It does not explicitly state when to call this versus rescan_findings or list_findings, so it falls short of full when/when-not coverage.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description reinforces this by framing the tool as a pure state readout with no mutation. It discloses what state is reported but adds nothing about freshness, whether values are cached, or any error conditions, so it stays at the baseline for an annotated read-only tool.

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

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

A single sentence with zero filler, front-loaded on the primary fact (whether the proxy is running) and then the secondary details. Every clause corresponds to a distinct returned field.

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

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

With no output schema present, the description carries the burden of telling the agent what comes back, and it does so by naming all four reported facts. Combined with annotations covering the read-only profile and an empty input schema, an agent has everything needed to call and interpret 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?

The tool takes zero parameters, so per the rubric the baseline is 4. The description correctly implies a no-argument, unconditional call with nothing for the agent to supply or infer.

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?

States a specific verb ('Return') and resource ('the MITM proxy') and enumerates exactly what state is reported: running state, bound port, TLS interception configuration, and buffer entry count. This clearly separates it from the other status-style sibling get_ca_status, which concerns certificate authority state rather than the live proxy process.

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 rather than stated: it is evidently a pre-flight/health check before start_capture, stop_capture, or traffic inspection, but the description names no alternative and gives no explicit when-to-use or when-not-to-use conditions. Adequate for a no-argument status tool, but nothing is spelled out.

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?

Annotations declare the write/non-idempotent/non-destructive profile, and the description adds real behavioral context beyond them: the released request resumes to the upstream or back to the client depending on which side was paused, and optional overrides mutate the request before release. It stops short of noting that a released breakpoint cannot be re-released or what happens on an invalid id.

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

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

Two sentences, front-loaded with the core action and outcome, with the optional-edit note second. No filler and nothing redundant.

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

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

With no output schema and 100% schema coverage, the description needs only to convey behavior, which it does. Minor gaps remain around failure modes and the fact that release is a one-shot operation, but nothing essential to invoking it correctly is missing.

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

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

Schema coverage is 100%, so the schema already documents id plus the four override fields. The description adds only that overrides mutate the request 'before release', which is mild added meaning; the baseline of 3 applies when the schema does the heavy lifting.

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?

States a specific verb (release) and resource (paused breakpoint) and explains the outcome: the request continues upstream or returns to the client depending on which side was paused. This is precise enough to distinguish it from list_paused_breakpoints and other traffic-control 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?

Usage is implied by the domain (you release a paused breakpoint obtained from list_paused_breakpoints, referenced in the schema) and the description hints at the optional edit path. However, it never states when this tool is appropriate versus alternatives, nor any prerequisites such as the breakpoint having to still be paused.

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?

Annotations already declare readOnlyHint=false and openWorldHint=true, so the agent knows this mutates external state. The description adds that the call goes to the 'real backend' and returns the upstream response, which partly compensates for the missing output schema, but it says nothing about side effects persisting upstream, auth requirements, or failure 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?

Two tight sentences: the core action leads, followed by the override caveat and the use case. No filler or 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?

For a moderately complex tool with fully documented params and no output schema, the description covers action, overrides, and return. It is nearly sufficient, though error/side-effect behavior on the upstream would complete the picture.

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 100%, so the baseline is 3. The description enumerates the override fields (method/url/body/headers) and calls them optional, matching the schema, but adds no syntax or format detail beyond it (e.g., the headers full-replacement nuance lives only in 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+resource ('Re-issue a captured request') and states the outcome ('return the upstream response'), making the operation unambiguous. It never names a sibling like get_request or replay_session, so the differentiation from those tools is left to inference.

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 explicit when-to-use conditions: 'verify a fix against the real backend or A/B between two URLs.' That is concrete context, but there are no exclusions or prerequisites (e.g., when to prefer get_session or replay_session instead).

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?

Annotations cover safety profile (readOnlyHint=false, idempotentHint=false, openWorldHint=true), so the description's remaining burden is smaller. It adds genuinely useful behavioral facts beyond annotations: returns one row per attempt with status/duration/error, and crucially that one failure does not abort the loop. This error-tolerance detail is not derivable from annotations.

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?

Three tight sentences, front-loaded with the action, then the return shape, then the failure-handling rule. Zero 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?

No output schema, so describing the return row (status, duration, error) is necessary and done. The non-aborting failure semantics fill a real gap. Missing only caveats like upstream reachability or whether it mutates captured state, which would fully close the loop.

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

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

Schema coverage is 100% and the single param 'id' is documented in the schema ('Session id from list_sessions'). Description adds no parameter detail. Baseline 3 is correct when the schema fully carries parameter semantics.

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?

Specific verb (re-fire) and resource (every captured request in a session) with scope stated precisely ('against the real upstream'). Distinguishes from replay_request sibling by operating on a whole session rather than a single request.

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

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

Implies usage via 'captured request in a session' and 'real upstream', giving context, but never states when to use this over replay_request, nor any prerequisites (capture must exist, upstream reachable). No exclusions stated.

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?

Annotations already disclose it is not read-only but idempotent and non-destructive, so the safety profile is covered. The description adds the return payload ('analyzed and findings counts') but does not explain whether existing findings are replaced or cleared during the rescan, which matters given readOnlyHint=false.

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?

Three tightly written sentences with the action front-loaded, followed by the trigger and the return shape. Every sentence adds distinct information with 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?

With no output schema, the description usefully states what is returned (analyzed and findings counts). Combined with the usage trigger and annotation coverage, an agent has enough to invoke it correctly.

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 takes zero parameters, so there are no argument semantics to document. The baseline for a parameterless tool applies, and the description correctly implies no input is needed.

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?

States a specific verb ('Re-scan') and resource ('every captured request through the findings detectors'), making the operation clear. It distinguishes itself functionally from read-only siblings like list_findings or get_findings_summary, though it does not explicitly name an alternative.

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?

Gives a concrete trigger condition: 'Useful after adding a redaction rule or changing detector config.' This is clear contextual guidance for when to invoke it. It stops short of stating exclusions or directly naming sibling alternatives.

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?

Annotations already declare this is a non-destructive, idempotent, non-read-only mutation. Beyond that, the description adds the meaningful outcome that the finding reappears in default views, which is the key behavioral effect. It does not cover permissions or return behavior, so it stops short of full disclosure.

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

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

A single front-loaded sentence that conveys the action and its effect with zero filler. Nothing to trim.

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 one-parameter restore operation whose safety profile is carried by annotations, the description is largely sufficient. The only minor gap is that it does not mention the return value, though no output schema exists and this is a low-complexity call.

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 100% schema description coverage on a single 'id' parameter, the schema already documents everything needed. The description adds no extra meaning about the parameter, so the baseline 3 applies.

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?

States a specific verb and resource ('Restore a previously dismissed finding') and describes the resulting state, so the action is unambiguous. It does not name the sibling dismiss_finding, but the inverse relationship is obvious from the resource and the 'previously dismissed' qualifier.

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 phrase 'so it appears in default views again' implies when this is used (reversing a dismissal), which is adequate context. However, it never names dismiss_finding or states a when-not condition, leaving the routing between the two siblings to inference.

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?

The annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuine value beyond that: it flags determinism, explicitly rules out an external LLM call, and states the return format (markdown). It stops short of noting any rate limits or failure 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?

Three front-loaded sentences with no filler; purpose, a key behavioral qualifier, and the output/chaining hint come in that order. The parenthetical chain example is slightly cryptic but still 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?

With no output schema, the description correctly steps in to state the return type (markdown) and how it is meant to be consumed. Combined with 100% schema coverage, an agent has enough to invoke this correctly, though the per-workflow input requirements are only in the schema, not the description.

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 100%, and the schema explains required/optional entry_id, session_id, and baseline_id per workflow. The description adds no parameter-level detail, so the baseline of 3 for a fully-documented schema applies.

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?

States a clear verb (Run) and resource (ProxyKit's built-in local workflows over engine data), and the deterministic/no-LLM clarification sharpens what kind of operation this is. No sibling in the list performs workflow execution, so no explicit differentiation is needed. The absence of the actual workflow names from the description is a minor gap, but the schema carries 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?

The chaining hint ("explain_failure → generate_issue → suggest_tests") implies a pipeline usage pattern, but the description never states when to reach for this tool versus doing analysis manually, nor any prerequisites. Usage is implied rather than stated, which lands at minimum-viable.

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 readOnlyHint=true already declaring the safety profile, the description still adds meaningful behavior: the search only covers 'a window of recent entries' rather than the full capture, and the limit defaults to 200. That windowed-scan disclosure is exactly the kind of non-obvious trait an agent needs.

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 tight sentences with the core purpose front-loaded and the scoping tip second; almost no waste. The only blemish is the dangling 'status' reference in the second sentence.

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-only search tool with full schema coverage and no output schema, the definition covers purpose, scanning scope, and a practical narrowing tip. Return format need not be described absent an output schema, leaving little genuinely missing.

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 100%, so all three parameters are already documented, making 3 the baseline. The description reinforces the method filter but also mentions a 'status' constraint that maps to no parameter, adding slight confusion rather than 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?

States a specific verb (substring search) and resource (captured URLs) with a clear scope of 'a window of recent entries'. It is distinguishable from a plain list operation, though it never names or contrasts with the sibling list_traffic, which is the closest alternative an agent would weigh.

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 one useful cue ('for very large captures, narrow the window with method+status first'), which is real when-to-use guidance. However, it offers no condition for choosing search_traffic over list_traffic, and it references a 'status' filter that does not exist among the parameters, so the guidance is partly unusable.

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?

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description usefully corroborates idempotency by stating that an already-running proxy returns the current status, but adds nothing about permissions, background lifecycle, or resource impact.

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?

Three short, front-loaded sentences with no filler; the core action comes first, followed by options and then the repeated-call behavior. Slightly more compact phrasing would be possible, but nothing is wasted.

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

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

With no output schema, the description partially compensates by noting that an already-running proxy returns the current status, giving the agent a signal about return content. It still leaves the exact shape of that status and the lifecycle of the started proxy unspecified, but for a two-optional-parameter tool this is reasonably 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 100%, and the schema already explains the port default and HTTPS MITM via local CA. The description only restates the two options at a high level, adding no syntax or behavioral nuance beyond the schema, so the baseline of 3 applies.

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 specific verb and resource ("Start the capture proxy") and immediately clarifies scope with the optional port and TLS interception. It does not explicitly distinguish itself from close siblings like proxy_status or stop_capture, though the "if already running" clause hints at the boundary.

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 by the verb and by the note about what happens if the proxy is already running, but there is no explicit when-to-use vs proxy_status or stop_capture guidance, nor any statement of prerequisites or side effects that would route an agent correctly.

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?

Annotations already declare readOnly=false, idempotent=false, destructive=false, so the mutation profile is covered. The description adds genuine context beyond that: traffic is tagged with the session id while active, and the call returns the new session record. It does not clarify duplicate-name behavior, but it is well above the annotation baseline.

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?

Three tight sentences ordered as purpose, behavior, return value, with no wasted words and the core action front-loaded. Slightly more prose than strictly necessary but every sentence carries information.

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

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

With no output schema, the description appropriately states what is returned ('the new session record'). Parameters are optional with sane defaults covered by the schema, and the tagging model is explained, so an agent has enough to invoke it correctly despite the missing when-to-use routing.

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

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

Schema coverage is 100%, so both 'name' and 'environment_id' (including the '0 or omitted = active environment' default) are already fully documented. The description adds nothing about parameters, which is acceptable given the schema does the work; baseline 3 applies.

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?

States a specific verb and resource ('Start a named session') and adds scope detail about traffic tagging, so the agent knows exactly what the call produces. However, it never distinguishes this from closely related siblings like start_capture or attach_environment, so it is clear but not sibling-differentiating.

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/when-not-to-use guidance and no named alternative. The phrase 'so the agent can later replay or compare it' hints at a downstream reason but does not state conditions under which one would choose start_session over start_capture or set up environment attachment first.

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?

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds meaningful context beyond that: it reassures that buffered entries are preserved, clarifying the side-effect scope of stopping capture.

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 short sentences, the action front-loaded and the side-effect caveat immediately after. No wasted words.

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

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

For a zero-parameter, no-output-schema lifecycle toggle, the description covers the essential behavior and the buffer-preservation effect. It could note whether capture can be resumed or what state results, but nothing critical is missing.

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 takes zero parameters, so the baseline is 4. There is nothing further for the description to clarify about inputs.

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?

States a specific verb ('Stop') and resource ('the capture proxy'), making the operation unambiguous and clearly the inverse of the start_capture sibling. It stops short of explicitly naming or contrasting with siblings like start_capture or stop_session, so it falls just below the top tier.

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 by the inverse relationship with start_capture, but there is no explicit when-to-use guidance or distinction from adjacent session-lifecycle tools such as stop_session or clear_traffic. The agent must infer the 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?

Annotations already declare readOnly=false, idempotent=true, and destructive=false, so the safety profile is known. The description adds genuinely new behavioral context beyond the annotations: stopping triggers an automatic rescan of captured entries for findings, which an agent should anticipate.

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 short sentences, action first, side effect second. Nothing is wasted and the most important information 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?

With no output schema, the description does the remaining work: it discloses the consequential post-stop rescan and the tool is simple (one required param, full schema coverage, annotations present). Only the resulting session state (e.g., whether it can be resumed or must be restarted) is left unstated.

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 100%; the single parameter 'id' is documented as 'Session id from start_session.' The description adds no additional parameter meaning, so the schema carries the load and baseline 3 applies.

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?

States a specific verb ('Stop') and resource ('active session'), and the 'active' qualifier scopes it away from list_sessions/get_session. However, it never distinguishes itself from the closely related delete_session sibling, leaving the agent to infer the difference.

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 when-to-use guidance, no prerequisites, and no naming of alternatives such as delete_session (removal) or rescan_findings (which overlaps with the auto-rescan behavior described). The 'active session' phrasing implies a precondition but does not state it.

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?

Annotations already declare the mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false). The description's "omit enabled to flip" usefully explains why the call is not idempotent — a state-dependent toggle — which is real added context. It stops short of covering permissions, invalid-id behavior, or what state changes result.

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 short sentences, zero filler, with the core action stated first and the flip fallback second. Nothing to trim.

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 two-parameter mutation with no output schema and annotations covering the safety profile, the description gives the agent everything needed to call it correctly, including the tri-state behavior of the optional flag. Only error/failure handling on an unknown id is left unstated.

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 carry the parameter meaning. It does the important work: enabled supplied means set explicitly, enabled omitted means flip the current value — semantics the bare boolean schema cannot convey. The id parameter is self-evident from the name.

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?

States a specific verb pair (enable/disable) plus the resource (chaos rule) and the lookup key (by id), so the operation is unambiguous. It does not explicitly distinguish itself from the nearby update_chaos_rule, but the toggle semantics differentiate it implicitly.

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?

"Omit enabled to flip" is genuine usage guidance for one call pattern and implies when the parameter is the right lever. However, there is no guidance on when to toggle versus use update_chaos_rule, nor any prerequisite or state context for choosing this tool.

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?

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false). The description adds genuinely useful context beyond them: this is a partial update that touches only the enabled field, and the omitted-parameter default flips the value rather than resetting it. It does not mention error behavior for bad ids or what the call returns.

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 short sentences with zero filler; the core action and the id-scoping constraint are front-loaded, and the default-behavior note follows immediately.

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?

No output schema exists, so describing the return value is not required, and the description covers the action, scope, and default behavior for a simple two-parameter toggle. Only missing piece is failure handling for an unknown id.

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 100%, so both parameters are already documented, and the description's note about omitting 'enabled' largely restates the schema. Baseline 3 applies when the schema carries the parameter 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?

States a specific verb pair (enable/disable) and resource (mock rule by id), and the clause 'without changing any other fields' implicitly distinguishes it from update_mock_rule. It never names the sibling outright, so an agent must infer the contrast rather than being routed to it.

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?

'Omit enabled to flip the current value' gives concrete usage for the optional parameter, which is real guidance. However, there is no explicit when-to-use-this-vs-update_mock_rule / toggle_chaos_rule / toggle_rewrite_rule statement and no mention of preconditions (e.g., rule must exist, paused state).

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?

Annotations declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the safety profile is partially covered. The description adds the default-flip behavior when 'enabled' is omitted, which is genuinely useful beyond annotations, but it doesn't disclose persistence, permission requirements, or the rule of what state results from a flip.

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 short sentences that front-load the core action and end with the key default-behavior detail. No wasted words.

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

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

For a simple two-parameter toggle with no output schema, the description covers the essential action and the omitted-parameter default. It leaves gaps around the meaning of the 'id' parameter and any return value or error conditions, but given the tool's simplicity and the annotation coverage, it is adequate rather than deficient.

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 carry parameter meaning. It explains the semantics of 'enabled' (omitting it flips the current value), which is helpful, but leaves the 'id' parameter (required, number) entirely unexplained beyond its name. This partially compensates but falls short of full coverage.

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?

Names a specific verb (enable/disable, i.e., toggle) and resource (rewrite rule) plus the identifier used to select it. It is clearly distinguishable from siblings like toggle_chaos_rule and toggle_mock_rule by naming the rewrite-rule resource.

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 via the 'Omit enabled to flip' clause, which effectively describes the two operating modes. However, it gives no explicit when-to-use guidance versus update_rewrite_rule (which could also change enabled), and no prerequisites or alternative selection logic.

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?

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the bar is lower. The word 'Partial' usefully discloses that only supplied fields are modified and the rest are preserved, but the description says nothing about the destructive consequences implied by the annotation or what happens to untouched fields beyond that single word.

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

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

Extremely short and front-loaded, with no wasted sentences. However, 'Partial.' is a fragment that is under-specified rather than genuinely concise, and it leaves the reader to guess what partiality means operationally.

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 an 8-parameter destructive mutation with no output schema and no enum hints, the description is far too thin. It should explain partial-update semantics, field meanings/ranges, and the destructive behavior the annotations only flag.

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% across 8 parameters, so the description must compensate and largely does not. 'By id' covers the one required parameter, but the seven optional fields (delay_ms, throttle_kbps, error_rate_pct, corruption_mode, url_pattern, name, enabled) get no meaning, units, or ranges in either place.

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?

States a specific verb and resource ('Update a chaos rule by id') and the 'Partial' qualifier signals PATCH-style semantics, which distinguishes it somewhat from toggle_chaos_rule. It never names or compares against the sibling operations (create_chaos_rule, delete_chaos_rule, toggle_chaos_rule), so differentiation is left to inference.

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 prerequisites, and no reference to alternatives such as toggle_chaos_rule (for flipping enabled) or update_mock_rule/update_rewrite_rule (for other rule types). 'By id' only implies the target, not the usage 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?

The patch semantics (unspecified fields retain current values) is a genuine behavioral trait not derivable from the annotations, and stating that the updated rule is returned helps with no output schema present. However, with destructiveHint=true the description never explains what is being destroyed or whether the change can be rolled back, leaving the most consequential annotation unelaborated.

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?

Three short sentences, front-loaded with the action and scope, then the argument rule, then the return value. No filler sentences.

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?

Mentions the return value, which compensates for the absent output schema, and covers the update semantics. It remains incomplete for a 10-parameter mutation tool where nine fields have no documented meaning or accepted value formats.

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 only 10% (just 'Mock rule id'), and there are 10 parameters. The description adds the cross-cutting patch rule but no per-field meaning, so ambiguous fields like dynamic and enabled are left undocumented in both the schema and the description.

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?

States a specific verb (update) and resource (mock rule) scoped by id, which cleanly separates it from the sibling update_chaos_rule and update_rewrite_rule on resource name alone. It does not explicitly call out the siblings or contrast with toggle_mock_rule, but the purpose is unambiguous.

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

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

The description gives a clear usage rule for the arguments ('Pass only the fields you want to change; missing fields keep their current value'), which is real guidance about partial updates. It says nothing about when to prefer this over toggle_mock_rule, create_mock_rule, or delete_mock_rule, and no preconditions are stated.

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?

Annotations already declare destructiveHint=true, idempotentHint=true and non-read-only, so the safety profile is covered. The description adds genuinely useful behavior beyond that: an unspecified field is left untouched rather than cleared, which is the key semantic of a partial update. It still omits permission/auth needs and reversibility.

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 tight sentences with the action and target front-loaded and no filler; the second sentence carries real information. Minimal but earned.

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 destructive 8-parameter mutation tool with no output schema and zero schema descriptions, the definition is too thin. It never characterizes the fields being edited (URL/match/method/rewrite action semantics) or the response, so an agent cannot reliably construct a call from the description alone.

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% across 8 parameters, so the schema contributes nothing and the description must compensate. It explains only that id selects the target and that unspecified fields are optional, leaving name/value/action/target/enabled/match_url/match_method entirely unexplained.

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?

States a specific verb (update) and resource (rewrite rule) qualified by id, which cleanly separates it from the create/delete/toggle/list rewrite-rule siblings. It stops short of explicitly naming an alternative, but the purpose is unambiguous.

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

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

"Partial — only changed fields need be passed" gives mechanical invocation guidance, but there is no statement of when to use this rather than toggle_rewrite_rule (for enabling/disabling) or the create/delete variants, and no prerequisites or exclusions.

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