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

Annotations already declare destructiveHint=true and idempotentHint=true, and the description restates idempotency while adding the consequential detail that a stopped monitor needs a new subscription to resume — real context beyond the annotation flags. It still says nothing about required permissions or what the cancellation response contains.

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

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

Three short, front-loaded sentences with no filler, lead sentence states the action and the ID sourcing rule. The middle sentence ('Select the intended subscription by name, source endpoint and catalog event; names are not cancellation keys') is slightly convoluted and could momentarily read as endorsing selection by name.

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

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

With an output schema present, return values need not be explained, and the annotations already carry the destructive/idempotent profile. The description covers the ID sourcing and the irreversibility consequence, leaving only auth/permission expectations unaddressed.

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

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

Schema description coverage is 100% and the property description already states 'Exact subscription ID returned by subscription_list. Never use a display name or endpoint ID.' The prose largely echoes that, so it adds little semantic value beyond the schema; baseline 3 applies.

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

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

States a specific verb and resource ('cancelling one Port OS event subscription') and scopes it to a single subscription by exact ID. It also implicitly distinguishes itself from subscription_list and subscription_inspect by naming them as the ID sources rather than as the operation itself.

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 directs the agent to obtain the ID from subscription_list or subscription_inspect and warns that names are not cancellation keys, which is the main misuse path for a cancel tool. It does not, however, discuss when cancellation is inappropriate or what alternatives exist for temporarily pausing a monitor.

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