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

With no annotations, the description carries the full burden and does disclose the key behavior: the tool does not actually disable anything and returns a structured feature_not_available response. This is a significant, non-obvious behavioral trait that an agent must know before calling the 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 compact and front-loaded, with no filler; both clauses add information about intent and current behavior. It is slightly too terse to replace missing schema documentation, but as a standalone text it is efficient.

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 stub with an output schema, the description covers the availability status and return shape. However, it omits all parameter semantics and usage conditions, leaving a caller without enough information to construct a 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%, and the description never mentions the required id parameter, its meaning, or how it relates to 'path'. The agent cannot determine whether id refers to a link ID, short code, or URL path from the description alone.

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

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

The description opens with a concrete action, 'Disable/block path', which aligns with the title and distinguishes it from read/create siblings like get_link and create_qr. The 'not live yet' qualifier and the stated feature_not_available return make the current intended behavior clear, though 'path' instead of 'link' is slightly ambiguous.

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 should not be invoked yet ('not live yet') but never states when to use it or what to use instead. No alternative sibling is named, and there is no guidance about what an agent should do if a caller needs to disable a link.

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