Alias cũ của cloud_service_stop

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

No annotations are present, so the description carries full responsibility for behavioral disclosure. It only says the tool is a compatible alias, without stating what the operation does, its side effects, or any permission requirements. An agent cannot tell from this description alone that the tool stops a service.

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, front-loading the alias status and the canonical replacement. It is appropriately short and efficient for a deprecation notice. Some additional operational context would improve value, but nothing here is wasted.

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 sufficiently routes an agent to cloud_service_stop for new integrations, which is valuable in context. However, it is thin regarding actual invocation of this alias, including the operation's behavior, return value, and parameter semantics. It is minimally adequate because the canonical sibling can supply the missing 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 description contains zero parameter information, while schema coverage is only 50% (sandbox is described, service_id is not). With such incomplete schema coverage, the description needed to compensate but did not. An agent receives no help understanding service_id or how sandbox interacts with what the alias does.

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 tool's role as a compatibility alias and names the canonical tool cloud_service_stop, making its purpose unambiguous. It doesn't state the underlying operation (stopping a service), but as a deprecated alias, its purpose is accurately communicated. It distinguishes itself from siblings by being the old alias of cloud_service_stop.

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 to use cloud_service_stop for new integrations, providing a clear alternative and the condition for choosing it. This directly tells an agent when not to use the alias. The guidance is actionable and leaves little room for misinterpretation.

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