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 usefully discloses the transport ('Proxies to /uapi/subscriptions/* with a server-minted Bearer key'), implying auth is handled for the caller. However, for a tool with destructive actions (plan_delete, subscription_cancel, payment_refund), it does not itself explain mutation/reversibility semantics beyond what the schema's action/confirm descriptions already say.

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 dense sentences that are front-loaded with the module identity and scope. Every sentence carries routing, prerequisite, or transport information with no filler. Slightly more information density than strictly necessary but well-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?

For a high-complexity 33-action tool with no output schema, the description covers scope, prerequisites, and transport but does not explain return shapes or how to navigate the action surface. The essentials for correct invocation (select_site, modules_tool, confirm) are present, but the coverage feels thin relative to the surface area.

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 79%, so the schema already documents most of the 33 parameters, including enums for action and type. The description adds no parameter-level syntax or format detail beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description names the resource domain precisely (subscriptions module) and enumerates its functional areas: tariff plans, user subscriptions, access checks, and payments. It explicitly excludes siblings ('Not shop_tool, users_tool, or content_tool'), so an agent can place it against alternatives. It stops short of 5 because the tool is a 33-action mega-tool and the description gives no per-action verb precision.

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 concrete prerequisite ('call select_site first') and an install gate ('Module must be installed via modules_tool'), plus negative routing against three siblings. This is clear when-to-use and when-not-to-use context. It lacks guidance on choosing among the 33 actions, which keeps it from a 5.

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