StartInstances

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

With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions this is for batch operations and gives usage scenarios, it doesn't disclose important behavioral aspects: whether this requires specific permissions, what happens if some instances fail to start, whether there are rate limits, what the expected response looks like, or whether this operation is idempotent. For a mutation tool with zero annotation coverage, this is a significant gap.

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 appropriately concise with two clear sentences. The first sentence states the core functionality, and the second provides usage context. There's no wasted verbiage or unnecessary repetition. However, it could be slightly more front-loaded by making the batch nature more prominent earlier.

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 annotations and no output schema, the description is insufficiently complete. It doesn't explain what the tool returns, what error conditions might occur, or important behavioral constraints. Given that this performs a potentially significant operation (starting cloud instances), more contextual information about permissions, idempotency, and failure modes would be valuable.

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 doesn't mention any parameters directly, but with 100% schema description coverage, the schema already documents both parameters (InstanceIds and RegionId) adequately. The description's mention of '批量' (batch) operation aligns with the InstanceIds array parameter, but adds minimal semantic value beyond what the schema provides. The baseline of 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 clearly states the action ('批量启动' - batch start) and resource ('ECS实例' - ECS instances), making the purpose immediately understandable. It distinguishes from siblings like StopInstances and RebootInstances by focusing on starting rather than stopping or restarting. However, it doesn't explicitly differentiate from StartRDSInstances (which starts RDS instances rather than ECS instances).

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 provides usage context with examples ('应用部署和高可用性场景' - application deployment and high availability scenarios), which helps understand when this tool might be appropriate. However, it doesn't explicitly state when NOT to use this tool or mention clear alternatives like RunInstances (for creating and starting new instances) or RebootInstances (for restarting already running instances).

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