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

With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a diagnostic/read-only operation but doesn't disclose response format (e.g., success/failure details), error conditions, or side effects (e.g., if it logs attempts). More context on what 'working' entails would help.

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

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

The description is a single, direct question that efficiently conveys the tool's intent without redundancy. It's front-loaded and wastes no words, making it easy for an agent to parse quickly.

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

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

Given the tool's simplicity (0 params, no output schema, no annotations), the description is minimally adequate. However, it lacks details on what a successful/failed check returns, which is crucial for a diagnostic tool. Without annotations or output schema, more behavioral context would improve completeness.

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

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

The tool has 0 parameters with 100% schema coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, aligning with the schema. A baseline of 4 is applied as it avoids unnecessary parameter details.

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

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

The description clearly states the tool's purpose as checking credentials and connection to PCE, using specific verbs ('check', 'working') and identifying the resource (PCE). However, it doesn't explicitly differentiate from siblings like get-events or get-workloads, which are data retrieval tools rather than connectivity checks.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., after credential setup), exclusions (e.g., not for data operations), or relate to sibling tools like get-events for actual data access after connection verification.

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

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

With no annotations, the description carries the behavioral disclosure burden. It does disclose that secret values are not revealed, which is useful, but it does not state whether the tool returns a simple boolean, what happens when no credentials are registered, or whether any read-only guarantee applies beyond not revealing secrets.

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

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

The description is a single sentence with no filler. It front-loads the core action and immediately follows with the important privacy qualifier, making every word meaningful.

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 status check, the description covers the essential purpose and a key behavioral constraint. It is slightly incomplete because there is no output schema and the description does not explicitly state the return value format, though 'check whether' strongly implies a boolean or status result.

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

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

The tool has zero parameters, so the schema already fully documents that no input is needed. The description adds useful context by clarifying that the check is for the current user and that secret values are not exposed.

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: checking whether PCE credentials are registered for the current user. It also adds the distinctive qualifier 'without revealing the secret values,' which sets it apart from registration and deletion tools among the 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?

The purpose is clear, so an agent can infer this is for verifying credential registration status. However, it does not explicitly say when to use this versus check-pce-connection or register-pce-credentials, nor does it mention any exclusions or 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?

With no annotations, the description carries the full burden of behavioral disclosure. It does well by stating this is a comparison operation that 'shows' changes, strongly implying a non-mutating preview rather than an actual provisioning action. It also discloses exactly what categories of changes are reported (new, modified, deleted), though it does not discuss output format, limits, or side effects.

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

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

Two focused sentences with no filler. The action and purpose are front-loaded, and the output detail is compressed into a single clear list. 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?

Given the tool's low complexity (one optional enum parameter, no required inputs, no nested objects), the description is largely complete for selection and invocation. It explains what the tool does, why you would use it, and what kinds of results to expect. The absence of an output schema or more explicit return-format details is a minor gap, not 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 schema already documents the single parameter fully with an enum, a default, and a description, so schema coverage is 100%. The tool description adds little parameter-specific meaning beyond listing resources conceptually; the baseline of 3 is appropriate because 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 begins with a clear, specific action: 'Compare draft vs active policy' and names the resource (policy) plus the purpose ('to see what would change on provisioning'). It also enumerates the output categories (rulesets, rules, IP lists, services), making the tool's function distinct from siblings like provision-policy or get-rulesets.

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 'to see what would change on provisioning' implies this is a pre-check tool used before applying a draft, which provides some usage context. However, there is no explicit when-to-use/when-not-to-use guidance and no named alternatives or exclusions, so the guidance is implied 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?

With no annotations, the description carries the full burden of behavioral disclosure. It states the tool identifies workloads and verifies segmentation policies, but does not explicitly say whether it is a read-only operation, what it returns, or whether there are side effects. 'Check' implies read-only but is not stated.

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

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

The description is two sentences and front-loads the primary purpose. It is concise with no wasted words, though a more structured breakdown of parameters could improve scannability.

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 should explain what a successful check returns or how results are presented. It does not describe return format, error conditions, or how lookback_days influences traffic analysis. For a tool with moderate complexity and no annotations, this is a notable 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?

Schema coverage is 100%, so the schema already documents each parameter. The description mentions 'specific compliance scopes' and 'framework requirements' but does not elaborate on how app_name, env_name, framework, or lookback_days affect the check. Minimal added value beyond 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 specific verbs ('check', 'identifies', 'verifies') and names the resource (policy compliance) alongside concrete frameworks (PCI-DSS, NIST, CIS). It clearly distinguishes this as a compliance-checking operation, though it doesn't explicitly contrast with sibling tools like enforcement-readiness or get-policy-coverage-report.

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 usage guidance is provided. The description does not state when to use this tool over alternatives, nor does it mention any prerequisites, exclusions, or conditions that would route an agent here.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden and meets it: it flags 'WRITE OPERATION: changes PCE state,' discloses that gated clients pause for user approval, and warns that 'the call has not failed and must not be retried while waiting.' It also discloses the priority-ordering behavior (override deny blocks above all). This is exactly the operational context an agent needs to avoid retrying a write that is merely awaiting approval.

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

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

The description is front-loaded with the core action, then structured with a numbered list for processing order and an all-caps 'WRITE OPERATION' flag for the critical warning. Every sentence carries distinct information — purpose, priority semantics, use cases, exclusion, order, and retry behavior — with no filler or repetition of schema content.

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 write operation with no annotations and no output schema, the description covers the invocation semantics, use-case selection, priority behavior, and the approval-gating pause comprehensively. The remaining gaps are minor: it doesn't state what a successful response returns or how conflicts with existing rules are handled. These are non-blocking for correct invocation.

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 adds meaning on top by explaining the full rule processing order (1-5), which gives the override_deny parameter its operational weight, and by reinforcing the 'must not happen under any circumstances' semantics. It does not add much for consumers/providers/ruleset addressing, but the schema already documents those thoroughly.

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: 'Create a deny rule in an existing ruleset,' and immediately defines what a deny rule does (blocks specific traffic, processed after allow rules). It clearly distinguishes override deny rules from regular deny rules, and the tool is unambiguously differentiated from siblings like delete-deny-rule, update-deny-rule, create-ruleset, and create-ringfence.

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 explicit when-to-use guidance: override deny for 'emergency isolation, hard compliance blocks, or active attack response' and an explicit exclusion — 'NOT for normal segmentation or ringfencing.' The numbered processing order also tells the agent where deny rules sit relative to allow rules. The only gap is that it never names the alternative sibling tool (e.g., create-ringfence) for the normal segmentation case, leaving that 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by declaring this a WRITE OPERATION that changes PCE state and explaining the approval-pause behavior and the no-retry rule. This adds significant value beyond the tool name. It could additionally mention the success return format, but the disclosed behavior is substantial.

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

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

The description is two tightly written sentences with no wasted words. The primary purpose is front-loaded, and the behavioral warning follows. It's efficient and well-structured, though slightly below a 5 because it packs the approval-gating note somewhat densely without formatting breaks.

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 create operation with no output schema and no annotations, the description covers the write nature and approval behavior well but doesn't describe what a successful call returns or any prerequisites (e.g., permissions). It's adequate for a straightforward create tool but leaves the agent to infer the response shape.

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 adds no parameter-level detail beyond what the schema already documents for name, ip_ranges, fqdn, and description. The schema fully covers parameter meaning, so the description correctly leaves this to the structured data.

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: 'Create a new IP List in the PCE'. The create/update/delete/get verbs on the sibling tools make the action unambiguous. It doesn't explicitly name sibling differentiators, but 'Create' vs 'update-iplist', 'delete-iplist', and 'get-iplists' is self-evident enough to warrant a 4 rather than 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?

The description provides useful contextual guidance about the approval gate in clients like Claude Desktop/Code and explicitly warns against retrying while waiting. However, it doesn't state when to use this tool vs alternatives (e.g., when to create a new IP list vs updating an existing one with update-iplist), so usage context is implied rather than explicit.

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

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

With no annotations, the description takes on the transparency burden. It explicitly states this is a write operation that changes PCE state and explains the approval-gating behavior in clients, including the key caveat that the call must not be retried while waiting. This is valuable behavioral disclosure beyond the schema.

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

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

Two sentences and no filler. The first sentence states the action, and the second delivers a necessary operational warning. Well front-loaded and appropriately sized.

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

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

The definition covers side effects and approval handling, which is important for a write operation. However, with 0% schema coverage and no explanation of key/value semantics, valid label types, response behavior, or potential uniqueness constraints, the description is not fully self-sufficient for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate for the undocumented key and value parameters. It mentions 'a specific type and the value' but never explicitly maps type to the key parameter or defines allowed/formatted values. An agent would struggle to confidently populate the parameters.

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

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

The description names a concrete operation—'create a label'—with a resource (label) and context (PCE). It is not a tautology and is distinguishable from update-label and delete-label. However, the phrase 'a specific type and the value' is slightly vague and does not explicitly say key/value.

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 no guidance about when to choose create-label over update-label or delete-label, and names no alternatives or preconditions. The retry warning is about post-invocation 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?

With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It explicitly flags 'WRITE OPERATION: changes PCE state,' explains that gated clients may pause for user approval, warns that the call should not be retried while waiting, and details rule ordering and how deny rules are pushed to source workloads. This goes well beyond a generic 'update' warning.

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

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

The description is long but information-dense, with a numbered list breaking down the generated rules and a clearly separated approval caveat. It is front-loaded with the core purpose. Some detail, such as selective-mode rule ordering, is repeated in the schema, so a couple of sentences could theoretically be trimmed, but the structure keeps it navigable.

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

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

Given the tool's complexity, nine parameters, and absence of annotations or output schema, the description is very complete: it explains side effects, approval behavior, generated rule types, and coarse-grained intent. The main gap is that it does not describe what the API returns or how to interpret the response after the approval completes, though that is not strictly required for correct invocation.

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 and the description does not need to re-document parameters. It does add high-level context by explaining the overall policy structure and selective-mode rule ordering, but it does not add unique meaning for most individual parameters beyond what the schema already states.

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 first sentence states a specific verb and resource: 'Create a ringfencing policy for an application.' It then distinguishes the tool's behavior from general policy creation by detailing the intra-scope and extra-scope rules it generates. This makes its function clear even alongside siblings like create-ruleset and ringfence-batch.

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

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

The description gives clear context: use this when you need a coarse-grained segmentation policy discovered from traffic flows. It explains what the result looks like and even warns about approval pauses in gated clients. However, it does not explicitly contrast itself with alternatives such as ringfence-batch or create-ruleset, so it lacks explicit when-not-to-use 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?

With no annotations provided, the description carries the full behavioral disclosure burden. It explicitly warns that this is a WRITE OPERATION that changes PCE state and describes the approval-pause behavior in gated clients, including the important warning that the call must not be retried while waiting. This is strong context, though it does not cover post-approval outcomes or failure semantics.

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

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

The description is two efficient sentences with no filler. The most operationally important facts—that this is a write operation and that gated clients pause for approval—are front-loaded, and every clause adds useful information.

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

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

The write/approval behavior is clearly conveyed and the schema covers most parameter semantics, but the description omits guidance on how this tool relates to the ring-fencing sibling tools and does not describe result/return behavior in the absence of an output schema. For a complex create operation with no annotations, this is adequate but not fully 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 75%, and the schema already provides rich parameter-level documentation for scopes, rules, ingress/egress services, and name uniqueness. The tool description itself adds no parameter-specific meaning, so it stays at the baseline rather than exceeding what the schema already provides.

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: 'Create a ruleset in the PCE', which clearly distinguishes it from update/delete ruleset tools and from workload/IP-list creation tools. However, it does not differentiate it from the closely related create-ringfence or ringfence-batch sibling tools, so it stops one step short of a top score.

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

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

There is no explicit guidance on when to use this tool versus alternatives, such as create-ringfence, ringfence-batch, or create-deny-rule. Mentioning 'support for ring-fencing patterns' hints at relevance but does not tell an agent when this generic ruleset creation path is preferable to the ring-fence-specific tools.

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

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

With no annotations provided, the description carries the full burden and explicitly states 'WRITE OPERATION: changes PCE state.' It also discloses that clients may pause for user approval and that retrying during the wait is incorrect. This meaningfully informs agent behavior beyond the schema.

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

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

The description is three sentences with no filler: purpose, critical parameter constraint, and an operational warning. Every sentence earns its place, and the most important usage requirement 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?

For a create tool with no annotations and no output schema, the description covers the essential selection, parameter constraints, side-effect, and retry behavior. It does not discuss duplication, authorization, or the return value, but those are less critical for correct invocation.

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 baseline is 3, but the description adds real semantics beyond the schema: the at-least-one-of constraint, the consumer-side matching behavior of windows_egress_services, and the note that egress only takes process_name/service_name and must be paired with service_ports. This compensates well for what the schema alone does not convey.

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

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

The description opens with a clear verb and resource: 'Create a service in the PCE.' It then elaborates the three supported service definitions. It does not explicitly contrast with siblings like update-service or get-services, but the action and noun are specific enough for basic differentiation.

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

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

The description gives practical usage constraints: 'Supply at least one of service_ports, windows_services or windows_egress_services.' It also flags a conditional requirement for windows_egress_services needing a Windows VEN on the consumer. It does not explicitly name alternatives or when not to use this tool, so it misses the top benchmark.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It explicitly warns that this is a WRITE OPERATION changing PCE state and that gated clients may pause for user approval, adding important operational context beyond the tool name.

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

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

The description is very concise, with two sentences that each earn their place: one for purpose and one for critical write-approval behavior. It is front-loaded with the core action.

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

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

Despite the useful gating warning, the description omits parameter guidance, return-value expectations, and any constraints on labels or IP address formats. Since there is no output schema and no annotations, these gaps leave the tool only partially specified for an agent.

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

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

Schema description coverage is 0% and the description provides no information about 'name', 'labels', or 'ip_addresses'. The description does not compensate for the schema's lack of 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?

The description states a specific action ('Create') and a specific resource ('an Illumio Core unmanaged workload in the PCE'), making the tool's purpose clear. It also distinguishes itself from sibling tools like update-workload and delete-workload.

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 for creating unmanaged workloads, but it does not explicitly compare with alternatives or describe when not to use it. It gives clear context for the operation but no exclusions or alternative routing.

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

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

With no annotations, the description carries the full burden. It explicitly discloses that this is a write operation that 'changes PCE state' and warns about the approval pause in gated clients, advising against retries. This is valuable non-obvious behavior. It doesn't cover side effects or error cases, but for a single-parameter delete it is strong.

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

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

Two sentences with no filler. The purpose is front-loaded, and the critical operational warning follows immediately. Every word earns its place; the all-caps 'WRITE OPERATION' is a minor stylistic choice that doesn't harm clarity.

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 tool with one parameter and no output schema, the description sufficiently covers what it does and the most important runtime behavior (approval gating). Explicit return-value semantics would be nice but are not necessary given the simplicity and absence of an output schema.

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

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

Schema coverage is 100%: the href parameter is fully described with an example path format. The description merely restates 'by its href' without adding new detail, so it meets the baseline but does not exceed it.

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'), a specific resource ('deny rule from a ruleset'), and a selection mechanism ('by its href'). This clearly differentiates it from sibling tools like delete-sec-rule or delete-ruleset without needing to open schemas.

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 context is clear: use this when deleting a deny rule. It does not explicitly name alternatives (e.g., update-deny-rule for modification), but the operation is unambiguous given the sibling set. The approval-gating note provides additional operational context, though it is more about behavior than 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly labels the operation as a WRITE OPERATION that changes PCE state, and discloses that gated clients pause for user approval, warning that the call has not failed and must not be retried. This is exactly the behavioral context an agent needs beyond the action itself.

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, each earning its place: action, parameter selection rule, and critical behavioral warning. The most important information is front-loaded, and there is no filler.

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

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

For a low-complexity tool with two optional parameters and no output schema, the description fully equips an agent to invoke it correctly. It covers resource, identification method, exclusivity constraint, operation type, and client-side behavior. 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?

Schema coverage is 100% and both parameters have descriptions, so the baseline is 3. The description adds meaningful value by specifying the exclusive-or relationship between 'href' and 'name' ('but not both'), which is not captured in the schema itself.

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

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

The description opens with a specific verb and resource: 'Delete an IP List from the PCE.' This clearly distinguishes it from sibling tools like create-iplist, update-iplist, and get-iplists. No ambiguity about what the tool does.

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

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

The description explicitly instructs how to identify the resource: provide either 'href' or 'name' but not both. It clearly states the context for use ('Delete an IP List from the PCE'). It does not explicitly name exclusions or alternatives, but the operation is unambiguous and the identification rule is strong 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly warns that this is a write operation that changes PCE state and that approval pauses are not failures, which prevents dangerous retries. This is strong transparency beyond what the schema offers.

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

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

The description is brief and front-loaded with the core action and state-change warning. The only minor issue is the run-together phrasing 'PCE WRITE OPERATION', which could be misread, but overall 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 two-parameter delete operation with no output schema, the description covers the most important behavioral context, especially the approval-gating and retry guidance. It is not fully complete because it omits parameter semantics and any side effects of deleting a label, but it is adequate for basic invocation.

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

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

The schema has two required parameters, key and value, with 0% description coverage. The tool description does not explain what key and value represent, how they identify the label, or any constraints on their values. The names imply they are label identifiers, but the description provides no real semantic help.

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

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

The description clearly states the action ('Delete a label') and the target resource ('in the PCE'), and explicitly characterizes it as a write operation. It does not explicitly contrast with siblings like create-label or update-label, but the verb and resource make the intended operation clear.

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

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

The description gives useful operational guidance by warning that gated clients pause for approval and that the call must not be retried while waiting. However, it does not provide explicit guidance about when to choose delete-label over alternatives such as update-label or create-label.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it delivers. It explicitly states this is a WRITE OPERATION that changes PCE state, discloses idempotency, and warns about approval pauses in gated clients with the crucial guidance that the call has not failed and must not be retried while waiting. This is exemplary behavioral transparency.

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

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

The description is compact and front-loaded: the core action is in the first sentence, followed by essential behavioral notes. Every sentence earns its place, covering action, idempotency, side-effect, and client-gating behavior without 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 parameterless, no-output-schema tool, the description is complete. It tells the agent what is removed, what side effects occur, how to handle approval delays, and that failure is not implied. 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?

The tool has zero parameters, so the baseline is 4; no parameter semantics are needed. The description accurately reflects that the operation targets the current user's credentials without requiring additional inputs, which fully covers the parameter dimension.

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 ('Remove') and a precise resource ('the current user's stored PCE credentials'), clearly distinguishing it from sibling tools like register-pce-credentials and check-pce-credentials-status. An agent knows exactly what operation this performs.

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 clearly establishes when this tool is appropriate: remove stored credentials for the current user. It also adds important usage context by noting the operation is idempotent and safe to call even when no credentials are stored, so the agent need not pre-check. It does not explicitly name alternatives, but for a simple delete operation the usage context 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?

With no annotations provided, the description carries the behavioral disclosure burden. It explicitly flags this as a WRITE OPERATION that changes PCE state and warns that gated clients will pause for approval, emphasizing that retries are inappropriate while waiting. This is valuable context beyond what the schema or name alone would 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?

Two sentences with no filler: the first fronts the core purpose and the second delivers a critical non-obvious operational warning. Every word earns its place, and the all-caps 'WRITE OPERATION' usefully emphasizes the mutation risk.

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 destructive tool with no output schema and no annotations, the description covers the essential behavior: what is deleted, what changes, and how approval-gated clients behave. It does not describe post-approval responses or failure modes, but this is minor for such a simple operation.

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

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

Schema coverage is 100% for the single href parameter, and the schema already includes a descriptive example. The description merely says 'by its href' without adding format constraints, validation rules, or behavioral meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description states a specific action ('Delete a ruleset from the PCE') and the required input mechanism ('by its href'). This clearly differentiates it from sibling delete tools such as delete-workload, delete-deny-rule, and delete-sec-rule by naming the exact resource type.

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 phrasing implies the tool is used when a ruleset needs to be deleted by href, but it does not explicitly contrast this with alternatives like update-ruleset or delete-deny-rule. No exclusions or prerequisites are mentioned beyond what the schema already states.

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

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

With no annotations provided, the description fully carries the burden. It declares 'WRITE OPERATION: changes PCE state,' which is a critical side-effect disclosure, and goes further to warn that in gated clients the call pauses for user approval and 'must not be retried while waiting.' This is exemplary behavioral transparency for a mutation tool.

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

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

Four short sentences with no filler. The core action, sibling alternative, side-effect warning, and retry instruction each earn their place and are ordered logically, from definition to operation to caveats.

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 delete tool with no output schema, the description supplies all essential context: what it does, when to use, side effects, and client-specific approval behavior. The only minor omission is what happens after approval, but that can be inferred from the call completing normally, so this is essentially 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?

The only parameter, href, has a 100% descriptive schema including an example. The description adds no extra parameter-level semantics, so it correctly rests on the schema. Baseline 3 applies by design.

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

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

The description opens with a specific verb and resource: 'Delete a single allow rule from a ruleset, leaving the rest of the ruleset intact.' It explicitly differentiates from the sibling delete-deny-rule by naming it and stating the condition ('For deny rules use delete-deny-rule'). This leaves no ambiguity about what the tool operates on.

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 explicitly tells the agent when to use this tool ('allow rule') and when not to ('For deny rules use delete-deny-rule'). The phrase 'leaving the rest of the ruleset intact' also signals that this tool is for single-rule deletion rather than deleting the whole ruleset. This is direct, actionable usage 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?

With no annotations, the description carries the full burden and does well: it explicitly flags 'WRITE OPERATION: changes PCE state' and explains the approval-pause behavior in gating clients, including that the call has not failed and must not be retried. This is valuable behavioral disclosure beyond the bare delete action, though it does not mention irreversibility 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?

The description is compact and front-loaded: purpose first, then state-change warning, then approval-pause guidance. Every sentence adds distinct value with 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 delete tool without an output schema, the description covers the essential operational context: the write side effect, the approval delay, and identifier selection. It could explicitly state that at least one of href or name is required, but this is reasonably implied and not a major 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?

Schema description coverage is 100%, so the schema already documents href and name. The description adds only a preference hint ('href preferred') without new semantic detail, so the baseline of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Delete a service from the PCE.' This clearly distinguishes it from sibling tools like delete-workload, delete-iplist, or delete-ruleset. The resource scope (PCE service) 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 parameter-usage guidance ('Identify by href (preferred) or name') but does not explicitly state when to use this tool versus alternatives like delete-workload or delete-sec-rule. The context is implied by the tool name and resource, but no exclusions or sibling comparisons are provided.

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

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

With no annotations, the description carries the full burden and does well: it labels the tool as 'WRITE OPERATION: changes PCE state' and warns that in gated clients the call pauses for user approval, adding that the call has not failed and must not be retried while waiting. This is significant behavioral context, though it does not discuss side effects or 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?

The description is three short sentences, each earning its place: the action, the identification guidance, and the critical behavioral warning. It is front-loaded with the main purpose and contains 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 destructive operation with no annotations and no output schema, the description covers the essential facts: what is deleted, how to identify it, that it changes PCE state, and the approval-gating behavior affecting retries. It omits finer details like permanence or cancellation handling, but is strong for this 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?

The schema already provides 100% coverage for both parameters, including the fact that name is an alternative to href. The description reinforces this with 'href (preferred) or name' but adds no new semantic information beyond what the schema already states, so the baseline of 3 is appropriate.

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

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

The description states a specific action and resource: 'Delete a workload from the PCE.' This clearly distinguishes it from sibling tools like delete-deny-rule or delete-iplist, and even from update-workload and create-workload, by naming the workload as the target.

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 invocation-level guidance ('Identify by href (preferred) or name') but does not explicitly describe when to use this tool versus alternatives such as update-workload or other delete-* siblings. No exclusions or alternative routing is provided; the usage context is implied through the tool name and action.

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

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

With no annotations, the description carries the full burden. It does disclose the analytical nature ('Analyze traffic patterns', 'detect potential') and the key concept of bridge apps, implying a read-only, heuristic analysis. But it does not mention data dependencies, limitations, or whether results are approximate or require additional validation.

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 primary purpose is stated first, and the bridge-identification detail adds meaningful clarification without bloating the text.

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 moderately complex analysis tool with no output schema and no annotations, so the description needs to explain what the agent will receive and any important caveats. It gives only a high-level notion of output ('identifies apps that serve as bridges') and omits details about result structure, false-positive potential, or how the optional parameters shape the output. An agent would likely need to call it experimentally to understand the results.

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 input schema covers 100% of the parameters with clear descriptions. The tool description adds nothing beyond the schema about how these parameters influence the analysis, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Analyze') and resource ('traffic patterns') and clearly states the outcome: detecting lateral movement paths and identifying bridge apps. This is distinct from siblings like get-traffic-flows, which simply retrieve traffic data, so an agent can tell them apart.

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

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

The description makes the use case clear: when you need to find potential lateral movement paths or bridge applications. However, it does not explicitly contrast this with alternatives or state when not to use it, so the guidance is implied rather than 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?

No annotations are provided, so the description carries the full burden. It clearly discloses the output shape (ranked process-to-external-destination findings with port, protocol, user, policy decision, and volume) and the FQDN-over-IP resolution behavior. While it doesn't explicitly state read-only semantics, 'Find' and 'Returns' strongly imply a non-mutating operation.

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 dense sentences with zero filler. The core purpose is front-loaded, the return value is summarized in the middle, and the routing guidance to a sibling appears at the end. 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 9-parameter tool with no output schema, the description plus fully covered schema provides enough for an agent to call it correctly: purpose, output contents, FQDN preference, and when to choose it are all stated. A minor gap is not distinguishing it from find-unmanaged-traffic, but the main alternative get-traffic-flows is addressed.

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 input schema has 100% description coverage, so every parameter is already documented with defaults and filter semantics. The tool description adds general context about the findings' meaning but doesn't add parameter-level detail beyond the schema. A baseline of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Find which processes talk to destinations outside this PCE's managed estate', which precisely frames the shadow-IT question. It also names get-traffic-flows as the sibling to avoid, making the tool's unique role immediately clear.

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 states when to use this tool instead of an alternative: 'Use this instead of get-traffic-flows when the question is what is talking out, not show me all traffic'. This gives an unambiguous decision rule with a named sibling, requiring no 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?

With no annotations, the description carries the burden of behavioral disclosure. It does reveal the analysis process and the output, but it does not explicitly state that this is a read-only assessment or mention permissions, side effects, or underlying data sources. 'Assess' implies no mutation, but that is not made explicit.

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

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

The description is two concise sentences: the first states the outcome and method, the second states the deliverable. Every phrase earns its place, and the key purpose 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?

For a moderate-complexity assessment tool, the description covers what it analyzes, what it returns, and the inputs are fully covered by the schema. It lacks a score range or example output, but it is sufficiently explicit for an agent to select and invoke the tool 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%: app_name, env_name, and lookback_days are already documented in the input schema. The tool description adds no parameter-level meaning beyond the schema, so it meets the baseline of 3 but does not exceed it.

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

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

The description names a specific verb ('Assess') and a distinct resource ('whether an application is ready for enforcement'), and details the method ('analyzing traffic flows, existing policy coverage, and identifying potential gaps') and output ('readiness score and actionable recommendations'). This clearly differentiates it from siblings like get-traffic-flows or get-workload-enforcement-status.

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

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

The description implies the tool is for readiness evaluation before enforcement, but it never explicitly says when to use it versus related tools such as get-traffic-flows, get-policy-coverage-report, or compliance-check. There is no when-to-use / when-not-to-use guidance or naming of 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?

With no annotations provided, the description carries the full behavioral burden. It does usefully define the domain logic ('unmanaged' = no app/env labels on sources or destinations), but it does not disclose output shape, whether results are aggregated, query cost/scale implications, or anything about the return format — significant given the absence of an output schema.

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

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

Two sentences with zero filler: the first states the action and subject, the second defines the key term and its significance. The core function is front-loaded and every clause earns its place.

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

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

For a 4-param tool with fully documented optional parameters and sensible defaults, the call contract is reasonably inferable. However, with no output schema, the description should explain what results look like (return format, ordering by 'top'), and it also lacks routing guidance relative to the traffic-related siblings — both are gaps an agent must resolve elsewhere.

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 baseline is 3 and descriptors already document all four parameters. The description adds genuine meaning beyond the schema by defining 'unmanaged', which clarifies the central concept the direction parameter ('relative to managed workloads') depends on, adding value the schema alone does not provide.

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?

Description uses a specific verb+resource ('Find traffic involving unmanaged workloads or IP addresses') and defines the scope precisely: sources or destinations lacking app/env labels. The policy-blind-spot framing differentiates it semantically from sibling traffic tools like get-traffic-flows, though it never names a 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 context is implied by 'representing potential policy blind spots' — the agent can infer this is a discovery/analysis tool for surfacing coverage gaps. However, there is no explicit when-to-use guidance, no exclusions, and no mention of alternatives such as get-traffic-flows or detect-lateral-movement-paths that might overlap.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It implies a read-only operation and lists the returned fields, but it does not explain behavior around filtering, max_results, pagination, or potential prerequisites/errors. This is acceptable for a simple getter 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?

The description is two concise sentences with no filler. The main action and scope are front-loaded, and the second sentence efficiently summarizes the return fields.

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 getter with no output schema, the description covers the core purpose and the main output fields. It is slightly incomplete in terms of explicit usage guidance and behavioral caveats, but the schema fills in the parameter details.

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 does not add significant parameter-level meaning beyond what the schema already provides, but it does not need to because both parameters are already documented with clear descriptions.

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 (Get), a specific resource (container clusters), and the scope (registered in the PCE). It further distinguishes itself from workload-level sibling tools by naming cluster-specific output fields such as CLAS mode, kubelink version, and node count.

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

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

The description provides clear context for when to use the tool: querying container clusters registered in the PCE and viewing their status/version details. It does not explicitly mention when not to use it or point to alternatives, but the scope is clear enough for a simple list/get 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?

With no annotations, the description carries the burden of behavioral disclosure. It does add context by explaining what the profiles represent and how they control pod management. However, it does not disclose read-only expectations, filtering interactions, pagination, or what happens when no cluster_href is provided (that detail is only in the schema).

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

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

Two sentences, front-loaded with the action and scope, followed by a concise explanation of domain meaning. Every sentence earns its place and there is no redundant wording 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?

For a simple getter with three optional filters and no output schema, the description plus schema cover most invocation needs. However, the description alone does not mention how to discover the cluster_href (sibling get-container-clusters), nor what a typical response contains. It is adequate but leaves the agent to infer these details.

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 adds no parameter-specific meaning beyond the schema; the phrase 'for a container cluster' loosely aligns with cluster_href but doesn't explain filter semantics or combinations. The schema already handles parameter documentation adequately.

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

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

The description states a clear verb+resource: 'Get Container Workload Profiles for a container cluster.' It also adds a useful conceptual explanation of what these profiles are (mapping K8s namespaces to Illumio labels and enforcement modes). It does not explicitly distinguish itself from sibling tools like get-container-clusters or get-kubernetes-workloads, hence no 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 guidance on when to use this tool versus alternatives such as get-container-clusters, get-kubernetes-workloads, or update-container-workload-profile. The description implies a use case (inspecting profiles for a cluster) but never states conditions, exclusions, or preferred alternatives. The only usage hint (cluster_href behavior when omitted) lives in the schema, not the description.

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

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

No annotations are provided, so the description must carry the behavioral disclosure burden. It only states that events are fetched and that filtering is optional; it does not describe result ordering, pagination behavior, return format, or side-effect-free guarantees, all of which would be useful for a get 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?

The description is a single, front-loaded sentence with no filler or redundancy. It communicates the object and action efficiently.

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 tool, the core action is adequately conveyed, and all parameters are documented in the schema. However, with no annotations and no output schema, the description does not explain the return shape, default limits beyond the schema default, or how filters combine, leaving an agent to infer those details.

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 input schema covers all seven parameters with descriptions, including enum values and a default for max_results, so the description does not need to repeat parameter details. The description adds only the generic notion of 'optional filtering' and no extra semantic nuance, meeting the baseline for high schema 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?

The description states a clear verb ('Get'), a resource ('events'), and scope ('from the PCE'), so the core action is understandable. However, it does not elaborate on what kinds of events are included or differentiate itself from event-adjacent siblings like get-server-changelog, so it is not fully distinct.

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 'with optional filtering' implies this is a query/list operation, but no explicit guidance is given about when to use this tool versus alternatives. No alternatives are named, and there is no mention of prerequisites or context in which get-events would not be appropriate.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Get', implying a read-only operation, but does not mention authentication requirements, rate limits, default behavior when no filters are applied, pagination, or response format. This is a significant gap for a tool that could have side effects or return large datasets.

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

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

The description is a single, efficient sentence that front-loads the main action. It contains no extraneous words and gets straight to the point, making it easy for an agent to parse quickly.

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

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

For a tool with 5 optional parameters, no annotations, and no output schema, the description is too minimal. It does not explain the default behavior when no filters are provided (e.g., returns all lists), how max_results interacts with pagination, or what the response structure looks like. An agent may not know what to expect from the 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?

The schema has 100% description coverage for all parameters, so the baseline is 3. The tool description adds no additional parameter information beyond stating 'optional filtering', which is redundant with the schema. No extra value is provided beyond what the schema already documents.

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

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

The description clearly states the verb 'Get', the resource 'IP lists', and the context 'from the PCE'. This distinguishes it from sibling tools like create-iplist, update-iplist, and delete-iplist, making the tool's purpose 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 implies a read operation but does not explicitly state when to use this tool versus other get tools (e.g., get-rulesets, get-workloads). There is no mention of alternatives or exclusions, leaving usage context largely implied by 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It discloses that the tool operates in 'CLAS mode' and shows policy sync state, which adds context. However, it does not mention pagination behavior beyond the max_results parameter, whether the operation is read-only, or what happens when cluster_href is omitted (though the parameter description partially covers that).

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

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

The description is two sentences with no wasted words. The main purpose is front-loaded, and the second sentence adds useful output detail. It is appropriately sized for a tool with three parameters and no output 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?

The description is adequate for a read-style list tool, but with no annotations and no output schema, it could be more complete. It does not explain what 'CLAS mode' means, how policy sync state is represented, or how the tool behaves when no cluster_href is provided (though the parameter description covers the fallback). An agent could call it correctly, but some behavioral context 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 description coverage is 100%, so the schema already documents all three parameters. The description adds minimal parameter meaning beyond the schema: it mentions labels and policy sync state, which relate to the output rather than the parameters. Baseline 3 is appropriate because 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 ('Get') and resource ('Kubernetes Workloads (CLAS mode) from a container cluster'), and lists what it shows (Deployments, Services, other K8s objects, labels, policy sync state). It is clear enough to distinguish from the sibling 'get-workloads' (which likely targets non-container workloads), though it does not explicitly name that sibling.

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 context: it is for Kubernetes/container cluster workloads managed by Illumio, and the cluster_href parameter description says 'If omitted, lists all clusters first,' which gives some behavioral guidance. However, it does not explicitly state when to use this tool versus alternatives like get-workloads or get-container-clusters, nor does it provide exclusions.

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

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

No annotations are provided, so the description carries the full burden. It communicates a read-only list operation with optional filtering, but it does not disclose response format, pagination behavior, or default handling of deleted labels. This is minimal but not misleading.

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

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

The description is a single, front-loaded sentence with no filler. It conveys the resource, operation, and key capability without redundant elaboration.

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 list tool with well-documented optional parameters, the description is adequate but lean. It does not mention what a label is, what the response looks like, or any default behavior, which matters since there is no output schema and no annotations.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters clearly. The description adds no parameter-specific meaning beyond calling the filters 'optional,' which is appropriate but does not elevate the score.

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 ('Get') and resource ('labels') with a clear source ('PCE'), and optional filtering is mentioned. It is immediately distinguishable from the label mutation tools like create-label, update-label, and delete-label.

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 this is the tool to use when retrieving labels, but it does not explicitly state when to use it over alternatives or when not to use it. It provides no exclusions or comparative guidance, so 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?

No annotations are provided, so the description carries full behavioral burden. The verb 'Get' clearly indicates a read operation, but the description does not explicitly state that it is non-mutating, nor does it mention pagination behavior or response characteristics. The domain context is helpful, but behavioral detail beyond the verb is limited.

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

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

Two sentences with no filler: the first states the action and resource, the second provides essential domain context. The description is front-loaded with the primary purpose and each 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 list/retrieval tool with full parameter schema coverage and no complex behavior, the description is largely complete. It lacks an explicit output schema or description of the return format, but the concept of pairing profiles is defined well enough for an agent to know what the tool returns and when to invoke it.

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

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

Schema description coverage is 100%, so the schema already documents both parameters ('name' partial match and 'max_results' default 50). The tool description adds no additional parameter-level semantics, but with full schema coverage the baseline of 3 is appropriate.

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

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

The description clearly identifies the operation as 'Get pairing profiles from the PCE' and explains what pairing profiles are, which is a specific resource not covered by any sibling tool. The phrase 'initial enforcement mode and labels for VENs' adds useful domain context that distinguishes this from other get-* tools.

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

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

The description implies this tool is used when pairing profiles are needed, but it does not explicitly state when to prefer this tool over alternatives or when not to use it. No exclusions or sibling comparisons are provided, so usage guidance is implied rather than explicit.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the report's analytical purpose and the covered-vs-blocked framing, which is useful. However, it doesn't disclose whether the report is read-only, whether it triggers any background computation, or what the output format looks like. The description adds some behavioral context but leaves significant gaps.

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

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

Two sentences with no filler. The core action and purpose are front-loaded, and the second sentence adds the use-case context. It earns its place, though it could be slightly more compact.

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 report-generation tool with no output schema and no annotations, the description should clarify what the report contains and how it's returned. The covered-vs-blocked framing helps, but an agent still doesn't know whether the report is a file, a JSON object, or a summary. Given the tool's moderate complexity and the absence of structured metadata, this is a clear 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?

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds the high-level concept of 'traffic flows' and 'policy'd' but doesn't add meaning beyond the schema's parameter descriptions. Baseline 3 is appropriate since 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 ('Generate'), a resource ('policy coverage report for an app'), and the report's purpose ('showing what traffic is covered by existing rules vs what would be blocked'). This clearly distinguishes it from sibling tools like get-traffic-flows or get-rulesets, though it doesn't explicitly name a sibling 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?

The description implies when to use it ('Helps understand how much of an app's traffic is already policy'd'), which gives an agent a clear context signal. However, it doesn't explicitly state when not to use it or name alternative tools for related tasks like get-traffic-flows-summary or find-unmanaged-traffic.

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

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

With no annotations provided, the description itself indicates a read operation ('Get'), but it does not disclose filters' combine behavior (AND vs OR), pagination, or that it returns a list. It is adequate but minimal.

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

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

The description is one short sentence that includes the core purpose and key feature (filtering) with no fluff. It is appropriately front-loaded.

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

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

Given no output schema, the tool is a simple list operation with all parameters documented. The description is slightly sparse but sufficient for an agent to call it correctly; the lack of pagination details is minor.

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 five parameters are described in the schema. The description adds no extra param semantics beyond what the schema provides, matching the baseline of 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 clearly states the action (Get) and the resource (rulesets from the PCE), and mentions filtering. It is specific enough to distinguish from sibling tools like create-ruleset or delete-ruleset, though it does not explicitly name any sibling.

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 this is a read-only query tool with optional filtering, but it does not state when to use it versus alternatives (e.g., get-rulesets for listing vs. update-ruleset for modifying). No explicit conditions or exclusions are provided.

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

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

With no annotations, the description carries the behavioral disclosure burden. It explains that cached tools/list and response shapes are not refreshed on server changes, clarifies the semantics of the `unlearn` field, and states the no-PCE-connection requirement. This goes well beyond a basic changelog summary.

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

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

The description is compact and front-loaded: purpose first, then usage triggers and a behavioral caveat, then the no-connection note. Every sentence earns its place with no filler or redundant restatement.

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 optional-parameter introspection tool with no output schema, the description provides enough context for selection and invocation, including the stale-cache caveat and the unlearn behavior. The return structure is not detailed, but 'changelog' combined with the `since` parameter makes it sufficiently inferable.

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

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

The schema fully describes both parameters, so the baseline is 3. The description adds value by explaining the `unlearn` field as listing behavior changes that invalidate earlier assumptions, reinforcing the purpose of `unlearn_only` beyond the schema text.

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 'What changed in this MCP server,' giving a clear subject and intent. Among the PCE-focused sibling tools, its scope is unambiguous even though it does not explicitly name a sibling 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?

The description provides concrete triggers: call when behavior mismatches expectations, after a mid-session update, or before relying on assumptions from earlier in a long session. It also notes that no PCE connection is required. It lacks explicit when-not-to-use guidance, but the context is strong.

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

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It only restates the purpose; it does not explicitly state that this is a read-only operation, has no side effects, how filters combine (AND/OR), what happens with no filters, or any limits. 'Get' implies read-only, but that is not made explicit.

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

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

The description is a single, tight sentence with no filler. It front-loads the core purpose and filtering capability, making it appropriately concise and easy to parse.

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

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

With 7 optional parameters, no output schema, and no annotations, the description is too thin. It does not mention the return shape (e.g., list of services), filter combination logic, pagination, or default behavior for max_results. An agent would have to guess important invocation semantics.

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 7 parameters are already documented in the input schema. The description adds only 'optional filtering' and no parameter-specific meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('get') and resource ('services from the PCE'), and mentions optional filtering. It is clear enough to distinguish from sibling mutation tools like create-service, update-service, and delete-service, though it does not explicitly name alternatives or scope nuances.

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

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

No explicit when-to-use or when-not-to-use guidance is given. 'Optional filtering' implies this is the tool for retrieving services with filters, but the description does not direct the agent away from or toward any sibling tools, leaving usage context 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates a read operation via 'Get' but does not mention result size, pagination, time range behavior, defaults, or any side effects. For a tool with 13 parameters and no output schema, this leaves significant behavioral uncertainty.

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

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

The description is a single, tight sentence with no filler, front-loading the core action and resource. It loses a point only because its brevity sacrifices useful context, but as written it is efficiently structured.

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

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

Given the tool's complexity (13 parameters, 2 required, no annotations, no output schema), a one-sentence description is insufficient. It does not explain default behavior, how results are returned, the meaning of grouping, or how this relates to get-traffic-flows-summary, so an agent is left without key operational context.

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

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

Schema description coverage is only 54%, and the description adds no parameter-specific meaning beyond the generic phrase 'comprehensive filtering options'. It does not compensate for the undocumented parameters such as query_name, max_results, policy_decisions, or include/exclude_services.

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 clear verb and resource ('Get traffic flows from the PCE') and signals the main capability (comprehensive filtering options). It clearly identifies what the tool does, but it does not differentiate it from the sibling get-traffic-flows-summary, 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 guidance on when to use this tool versus the closely related get-traffic-flows-summary, nor any exclusions or alternative suggestions. 'Comprehensive filtering options' hints at a use case, but the description fails to state when an agent should pick this tool over its sibling.

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

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

With no annotations, the description carries the burden. It explicitly says the output is structured JSON, describes each section, and notes that the result is smaller than the sibling. It does not explicitly state read-only or auth requirements, but the 'get/summarize' verbs and non-destructive framing convey query behavior. No contradictions.

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

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

The description is a single compact paragraph that front-loads the core function, then lists output sections, then gives a decision rule. Every sentence carries 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?

For a 14-parameter tool with no output schema or annotations, the description is not fully complete: it covers the output shape and the sibling distinction well, but it does not explain how filters, max_results, query_name, or policy_decisions affect the summary. The schema fills in some gaps, but several ambiguous parameters remain, so an agent may still need to infer behavior.

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

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

The description provides no parameter-level guidance. Schema coverage is only 57%, leaving params like query_name, max_results, include/exclude_services, and exclude_workloads_from_ip_list_query without descriptions in either the schema or the tool description. The description's sections don't map to any input parameter, so it fails to 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 verb 'Summarize' plus resource 'traffic flows' makes the action and target explicit. Enumerating the four JSON sections (by_process, external_destinations, blocked, app_to_app) gives an agent a clear picture of what it will receive. It also explicitly differentiates from get-traffic-flows, so 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?

'Prefer this over get-traffic-flows for analysis' is an explicit routing instruction that names the sibling and the condition. The rationale ('far smaller and answers the usual questions directly') helps an agent decide correctly without needing to inspect get-traffic-flows.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It does add some behavioral context (grouping behavior and mixed-state detection) beyond the tool name. However, it does not disclose the response format, whether the operation is read-only, pagination behavior, or what happens when no workloads match.

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

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

Two sentences with the core purpose front-loaded and a useful second sentence about mixed enforcement states. No wasted words, though the structure could be slightly improved by explicitly noting the read-only nature.

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

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

Given the tool has 2 optional parameters, 100% schema coverage, and no output schema, the description is adequate but minimal. It explains what the tool does but not what the response looks like, which could matter for an agent deciding whether this tool provides the needed detail versus a more granular tool like get-workloads.

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% (both parameters are described as optional filters), so the schema handles parameter documentation. The description adds marginal value by implying the filters map to grouping dimensions (application and environment), but it doesn't add syntax or format details beyond 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 clearly states a specific verb ('get'), a resource ('enforcement mode status'), and adds context about grouping by application/environment and identifying mixed states. This makes the purpose understandable, though it doesn't explicitly distinguish it from related tools like get-workloads or get-rulesets.

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 when to use this tool (to check enforcement status across workloads) and mentions optional filtering via parameters, but it provides no explicit guidance on when to use it versus a sibling tool, nor any exclusions or alternatives. The usage context is clear enough but not explicitly 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?

With no annotations, the description carries the burden of behavioral disclosure. It adds scale context ('tabular overviews of thousands of workloads') and characterizes each detail mode, but it does not disclose output shape, pagination, default result limits, or any side-effect/permission considerations. The behavioral info is limited to what the schema already hints at.

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

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

Two sentences with no filler. The action is front-loaded and the detail_level guidance is compactly organized by the three enum values with default called out.

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 10 fully self-describing parameters and no output schema, the description is workable but leaves gaps: it doesn't mention pagination, max_results behavior, or how results are returned (e.g., JSON array vs nested structure). It is adequate but not complete enough to raise above average.

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 baseline is 3. The description adds value beyond the schema by explaining the breadth-vs-depth tradeoff and giving a practical rule of thumb for when each detail_level value is appropriate. This is meaningful enrichment of the most consequential parameter.

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

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

The description opens with a specific verb and resource ('Get workloads from the PCE') and clarifies the output options via detail_level. It does not explicitly differentiate from sibling tools like get-kubernetes-workloads or get-workload-enforcement-status, but the core 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?

It gives concrete guidance on choosing detail_level: compact for tabular overviews of thousands, full for specific workloads, labels_only for maximum breadth. However, it never says when to choose this tool over sibling alternatives such as get-kubernetes-workloads or get-traffic-flows, so tool-selection guidance is implied rather than explicit.

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

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

With no annotations, the description carries the behavioral burden. It frames the tool as read-only analysis ('Analyze traffic flows', 'Builds a graph', 'computes centrality metrics') and describes returned artifacts, but it does not explicitly state that no state is changed, nor cover edge cases such as insufficient flow data 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?

Three purposeful sentences: the first states the action, the second explains the computation, and the third gives the use case and output. No fluff, and the main verb 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?

For a read-only analysis tool with no output schema and no annotations, the description covers the important ground: purpose, method, return value, and why the result matters. It could add details on how to interpret scores/tiers or prerequisites, but it is not materially incomplete.

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 schema fully documents all three optional parameters. The description adds no parameter-specific meaning, but it also doesn't need to; 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?

The description opens with 'Analyze traffic flows to identify infrastructure services', a specific verb+resource pair, then clarifies the method (app-to-app graph, centrality metrics) and output (ranked list with scores, classification tiers, connectivity details). This clearly differentiates it from siblings like get-traffic-flows or get-traffic-flows-summary, which are raw/summary traffic tools.

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

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

The description explicitly grounds usage in a segmentation rollout context: infrastructure services 'should be policy'd first during segmentation rollouts.' This gives clear when-to-use guidance, though it does not name alternative tools or state when not to use it.

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

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

With no annotations provided, the description carries the full burden and does well: it explicitly flags WRITE OPERATION, notes PCE state changes, warns about user-approval pauses, and cautions that retries are inappropriate while waiting. It discloses the two-step token flow, though it leaves ambiguous how the token parameter is supplied since no token field appears in the schema.

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

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

Every sentence earns its place: purpose, scope, write warning, client behavior, and confirmation flow. The write warning is placed prominently and the two-step behavior is communicated in a compact sequence.

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

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

The description explains the operation well and partially covers return behavior by saying the first call returns a token. However, with no output schema and no token parameter in the input schema, the exact mechanism for passing the token back is unexplained, leaving an important gap for correct invocation.

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 input schema already documents both parameters at 100% coverage, including the important 'provisions ALL pending changes' behavior for omitted hrefs. The description adds little beyond that, so the baseline score 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: 'Provision pending draft policy changes in the PCE.' It clarifies exactly what changes state, naming the affected entity types and the draft-to-active transition, which distinguishes it from siblings like compare-draft-active or enforcement-readiness.

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?

Explains when to use the tool: to provision pending draft changes, either all pending changes or specific items by href. It does not explicitly name alternative tools or exclusions, but the described action and the two-step confirmation flow give clear 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?

With no annotations, the description fully carries the behavioral burden, and it does so well: it flags the mutation via 'WRITE OPERATION: changes PCE state' and explains the client-gating pause, including the critical instruction not to retry while waiting. Overwrite semantics are also disclosed.

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 convey purpose, effect, and a crucial behavioral warning with no filler. The most important operational facts are 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 write operation with no annotations or output schema, the description covers the essential context: what changes, what becomes available, the approval pause, and retry guidance. Together with fully documented parameters, 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?

Schema description coverage is 100%, so the schema already documents all seven parameters. The description adds no parameter-level meaning, which is acceptable but does not raise the 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 names a specific operation ('Register (or overwrite) PCE credentials') tied to 'the current authenticated user' and states the concrete effect: all PCE tools become available in the session. This clearly distinguishes it from sibling tools like delete-pce-credentials and check-pce-credentials-status.

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

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

The description makes the intended use obvious: register/overwrite credentials for the current user so PCE tools become available. It does not explicitly contrast with alternative status/check tools, but the overwrite wording and availability effect give clear context for when to call 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly labels the operation as a WRITE OPERATION that changes PCE state, warns that gated clients pause for user approval, states that the call has not failed and must not be retried, and discloses the two-step token requirement. This is strong and goes well beyond the schema.

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

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

The description is compact and well-organized. It opens with the purpose, then adds auto-discovery context, connects to create-ringfence, and finishes with side effects and the two-step workflow. Every sentence contributes useful information with no fluff 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 mutating, multi-step tool with no annotations and no output schema, the description covers the core behavioral contract: side effects, approval pause, retry guidance, and the token-return flow. It is slightly incomplete because the second-step token is not represented in the input schema, so an agent would still need to infer how to pass it back.

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 adds some context around auto-discovery, which maps to auto_order, and explains the confirm-token workflow. However, it does not elaborate on apps, dry_run, or lookback_days, and it mentions a token to pass back without a corresponding input-schema field, a minor inconsistency.

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 first sentence states the exact action and resource: 'Create ringfence policies for multiple applications at once.' The description also references 'the same logic as create-ringfence,' which lets an agent distinguish this batch tool from the single-application sibling without inspecting schemas.

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

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

The description gives clear operational context: it is for multiple applications, can optionally auto-discover infrastructure services first, and it explains the approval-gating and two-step confirm-token flow. It does not explicitly state when to use create-ringfence instead of this tool, so it falls just 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly marks the operation as a WRITE OPERATION that changes PCE state, and it explains the approval-gated behavior in Claude Desktop/Claude Code, including the critical instruction that the call should not be retried while waiting. This is unusually transparent and actionable.

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

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

The description is compact and front-loaded: it states the purpose, gives the key action, and then prominently warns about write behavior and approval gating. Every sentence earns its place, with no redundant filler or buried-critical warnings.

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

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

Given the 4-parameter tool with 100% schema coverage and no output schema, the description covers the essential operational context: purpose, how to trigger management, mutation side effect, and approval pause behavior. It does not describe return values or prerequisites in prose, but for this tool the schema and description together are sufficient.

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 input schema already documents every parameter. The description mostly rephrases what the schema says about managed and assign_labels without adding new syntax, constraints, or cross-parameter relationships. This meets the baseline but does not exceed it.

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

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

The description clearly identifies the verb ('Update'), the resource ('Container Workload Profile'), and the broader purpose ('manage Kubernetes pods in Illumio'). However, it does not explicitly differentiate this from sibling tools like update-workload or get-container-workload-profiles, so it stops short of full sibling distinction.

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

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

The description gives clear context and actionable guidance ('Set managed=true and assign labels to start managing pods in a namespace'), but it never says when to choose this tool over alternatives or when not to use it. There is no exclusion or alternative routing, so usage guidance is implied rather than explicit.

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

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

The description explicitly flags 'WRITE OPERATION: changes PCE state,' and goes further by explaining client-side approval gating and the critical retry warning: 'the call has not failed and must not be retried while waiting.' With no annotations provided, this is substantial behavioral disclosure.

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

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

Three tight sentences: the function, the write-operation warning, and the gating/retry note. Every sentence carries operational value, and the most critical behavior 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?

Between the description and the rich schema, all necessary parameters and the key side-effect behaviors are covered. There is no output schema and no mention of success or error responses, a minor gap for an update operation, but not enough to impede correct invocation.

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 (href, enabled, consumers, providers, ingress_services) already carries detailed descriptions and constraints. The description adds only minimal href identification guidance, so the baseline of 3 is appropriate.

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

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

Description states a specific action ('Update an existing deny rule in a ruleset') and the resource ('deny rule'), with the identifier mechanism ('by its href'). This clearly differentiates it from siblings like create-deny-rule, delete-deny-rule, and update-sec-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 phrase 'existing deny rule' implies this is for modifying an existing rule rather than creating or deleting, which is clear contextual guidance. It does not name explicit alternatives or when-not conditions, 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?

With no annotations provided, the description carries the full burden, and it excels: it explicitly flags 'WRITE OPERATION: changes PCE state' and explains that gated clients pause for user approval, adding that the call 'has not failed and must not be retried while waiting.' This is rich safety-relevant behavioral disclosure beyond the schema.

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

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

Three concise sentences with no filler: purpose, identifier rule, and safety behavior. The most important operational constraint is front-loaded, and 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 mutation tool with 5 optional parameters and no output schema, the description provides the essential identifier rule, the state-changing nature, and the approval-pause behavior. It could say whether unspecified fields are overwritten or describe the response, but the schema covers parameter details and the key behavioral gaps are addressed.

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 baseline is 3. The description adds meaningful parameter semantics by specifying the exclusivity constraint between href and name, which the schema only implies. It does not repeat field-level details already present 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?

Description starts with a precise verb-resource pair: 'Update an existing IP List in the PCE.' It clearly identifies the object type, the scope, and that it operates on an existing resource, which distinguishes it from create-iplist, delete-iplist, and get-iplists.

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 a clear operational rule: 'Provide either href or name (but not both) to identify the IP List.' This is strong usage guidance for invocation. It doesn't explicitly name alternatives like create-iplist or delete-iplist, but 'Update an existing IP List' implies the tool's context without excluding other cases.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It explicitly flags 'WRITE OPERATION: changes PCE state,' and crucially warns that approval-gated clients may pause and that the call must not be retried while waiting. This non-obvious, actionable behavior goes well beyond what the schema conveys.

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

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

The description is compact and front-loaded: purpose, invocation methods, then the critical write/approval warning. Each sentence earns its place. It loses a point for the misleading 'optionally with key' phrasing, which introduces ambiguity in an otherwise efficient structure.

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

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

The description covers the core purpose, invocation options, and a key behavioral warning, which is substantial. However, the key/href contradiction creates a real gap that could prevent correct invocation. It also does not mention what happens on success or how to handle cases where both identification methods are provided, making it minimally viable but not complete.

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

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

Although schema coverage is 100%, the description's parameter guidance contradicts the schema: it says href + new_value is used 'optionally with key,' while the schema states key is required when using href. This conflicting instruction can mislead an agent into constructing an invalid call. The description also does not clarify precedence if both href and key+value are supplied, so it subtracts value rather than adding it.

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

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

The description opens with a specific verb and resource: 'Update an existing label in the PCE.' This clearly distinguishes it from siblings like create-label, delete-label, and get-labels. It further clarifies the resource scope and that only existing labels are affected.

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

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

The description provides two explicit identification methods (href-based and key+value-based) and states that new_value is always required. This gives clear context on how to invoke the tool. However, it does not explicitly state when not to use it, such as pointing to create-label for new labels or delete-label for removals, so it falls 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?

With no annotations provided, the description carries the full burden and does so well. It explicitly labels the operation as a WRITE OPERATION that changes PCE state, and it warns that in gated clients the call pauses for user approval and must not be retried. This is valuable behavioral context beyond the schema.

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

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

The description is compact and front-loaded: it states the operation, then the key identifier constraint, then the critical write/approval behavior. Every sentence contributes necessary 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?

For a mutating tool with no annotations and no output schema, the description covers the main things an agent needs: what it updates, how to identify the target, and the approval-pause behavior. It could go further by explaining whether unspecified fields are left unchanged and what the response contains, but the core invocation guidance is 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%, so the baseline is 3. The description adds meaningful value by stating that either 'href' or 'name' must be provided but not both, which is a critical constraint not evident from the schema alone.

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

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

The description clearly states the tool updates an existing ruleset in the PCE, using a specific verb and resource. This distinguishes it from sibling tools like create-ruleset and delete-ruleset without requiring 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?

It gives clear usage context: updating an existing ruleset, rather than creating or deleting one. It does not explicitly name alternatives or provide when-not-to-use guidance, but the 'existing' qualifier and write-operation warning make the intended use 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?

With no annotations provided, the description carries the full behavioral disclosure burden and does so thoroughly. It flags 'WRITE OPERATION: changes PCE state,' explains that in gated clients the call pauses for user approval, and warns that 'the call has not failed and must not be retried while waiting.' It also discloses partial-update semantics with 'Only the fields you supply change.' These are meaningful behavioral traits beyond what the schema conveys.

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

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

The description is tightly written with no filler. It front-loads the core action and identification method, then efficiently covers the usage rationale, sibling routing, and the critical write-operation approval behavior. 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 mutation tool with no annotations and no output schema, the description is remarkably complete. It covers purpose, scope, the distinction from sibling tools, partial-update behavior, write side effects, approval-pause behavior, and a retry prohibition. The rich parameter schema covers field-level semantics, so nothing an agent needs to invoke this 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 baseline is 3, but the description adds real semantic value beyond the schema. Notably, it explains egress_services as a consumer-side process qualifier distinct from ingress_services, states that the PCE refuses a Windows egress service in ingress_services, and clarifies that both should be used together for 'this binary, to that port.' The partial-update statement also informs how all parameters behave.

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: 'Update an allow rule inside a ruleset, identified by its href.' It clearly distinguishes this from the sibling update-deny-rule by explicitly noting 'For deny rules use update-deny-rule.' An agent can tell exactly what this tool does and what it does not do.

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

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

The description provides explicit guidance on when to use this tool: 'Use this to refine a rule in place... instead of rebuilding the ruleset.' It also names the alternative for deny rules and gives a concrete example use case (swapping an inline port for a process-qualified service). This leaves no ambiguity about when to select it over siblings.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'WRITE OPERATION: changes PCE state,' which is the most important behavioral trait. It also discloses the approval-gating behavior in Claude Desktop/Claude Code and warns that the call 'has not failed and must not be retried while waiting.' This is exceptionally useful and prevents an agent from making a dangerous retry.

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

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

The description is three tightly packed sentences. The first sentence states the action and identification strategy, the second flags the write nature, and the third warns about approval gating and retry. Every sentence earns its place with 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 mutation tool with no annotations and no output schema, this description covers the essential call-time knowledge: what is updated, how to identify the target, that state changes, and how to handle approval pauses. It does not explicitly explain the effect of omitting fields, but the schema already documents replacement semantics for the array parameters. A short note on 'unspecified fields remain unchanged' would make it fully 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?

Input schema coverage is 100%, so the schema already documents all seven parameters thoroughly. The description adds only the guidance that href is preferred over name, which is a minor semantic clarification. No additional parameter-level meaning is missing because the schema already explains fields, nesting, and replacement 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?

The description opens with a specific verb and resource: 'Update an existing service in the PCE.' This clearly distinguishes the tool from create-service, delete-service, and update-* tools targeting other resources like workloads or rulesets. The identification mechanism (href preferred or name) further clarifies scope.

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

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

The description provides clear context for when to use the tool: when updating an existing service in the PCE, identified by href or name. It also implicitly distinguishes from creation by saying 'existing service.' It does not explicitly name alternatives or exclusions, but the resource-specific language is enough for typical routing.

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

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

With no annotations provided, the description carries the full burden for behavioral disclosure, and it does this exceptionally well. It explicitly flags this as a WRITE OPERATION that changes PCE state, and explains the user-approval gating behavior in Claude Desktop/Claude Code, including the critical warning not to retry while the call is paused.

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

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

The description is compact and front-loaded: the core action, identifier strategy, partial-update behavior, and the critical write/approval warning all appear in a few purposeful sentences. No filler or repetition of schema details.

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

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

For a mutation with 8 optional parameters, no required fields, and no output schema, the description covers everything needed to call it correctly: how to identify the target, how to specify partial changes, and what to expect during an approval-gated write operation. The absence of return-value details is acceptable without an output schema and given the clear operational warning.

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 all 8 parameters. The description adds meaningful selection semantics by stating that href is the preferred identifier, name is an alternative for finding the workload, and only provided fields will be changed. This exceeds the baseline expected when schema coverage is complete.

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 ('Update') and a specific resource ('a workload in the PCE'), and clarifies how to identify the target via href or name. This is sufficient to distinguish it from sibling tools like create-workload, delete-workload, and update-label.

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

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

The description gives clear practical usage context: identify by href (preferred) or name, and provide only the fields to change. It does not explicitly call out when not to use this tool in favor of create-workload or delete-workload, but the update semantics are stated clearly enough that an agent can infer the appropriate scope.

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