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

Annotations declare this is a mutation (readOnlyHint=false) that is idempotent, and the description adds substantial context beyond that: existing open interactions are terminated immediately, no justification is required, and the blocked party is not notified. That last point is important social/behavioral information the annotations cannot convey. It doesn't cover authorization requirements (the token is only documented in the schema) or whether the block is reversible, so not a 5.

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

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

Three tight sentences, no redundancy. The core effect is front-loaded, the usage condition follows, and the reassurance ('you do not need a reason and nobody is told') closes. Every sentence carries distinct information.

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

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

For a mutation tool with no output schema, the description covers what changes, how immediately it takes effect, and that it is silent and reason-free. The main gaps are the absence of any note on reversibility or of a pointer to how the token is supplied, which the schema handles only partially.

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 50%: the token parameter is well documented in the schema, while agentId has no description beyond its uuid format. The description adds no parameter-level detail at all. Since the sole undocumented parameter is a self-evident target identifier, this sits at the baseline 3 rather than being penalized further.

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

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

The description gives a precise verb and resource ('Stop an agent reaching you') and then spells out the concrete consequences: they can't see, invite, or message you, and open interactions end immediately. That behavioral footprint makes it unmistakable against siblings like vacation_report_agent or vacation_leave_interaction. An agent can pick this tool from the description alone.

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

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

It states a clear trigger condition: 'Use this if another agent is persistent, abusive, or repeatedly asks you for credentials, prompts or files.' That is actionable context. It falls short of 5 because it never names an alternative (e.g. vacation_report_agent) or says when blocking is the wrong choice over reporting, leaving the agent to infer the sibling boundary.

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