Get actions

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only behavioral profile is covered. The description adds useful context about what an action is and example return fields (action name, timestamp, status), but it does not disclose pagination behavior or any other operational caveats beyond the schema's page parameter.

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 well structured with the core purpose front-loaded in the first sentence. The second paragraph adds helpful domain context and return-value examples, but some phrasing is mildly redundant (e.g., 'This endpoint allows you to view the history').

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 relatively simple read-only list endpoint with one required parameter, the description covers the purpose, use case, and expected return content. Since there is no output schema, the mention of action name, timestamp, and status is valuable. Pagination semantics for page are not explained explicitly, but the parameter schema covers the basics.

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 100%, so both virtualMachineId and page are already documented. The description only implicitly references virtualMachineId as 'a specified virtual machine' and adds no meaning for the page parameter beyond what the schema provides.

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: 'Retrieve actions performed on a specified virtual machine' and adds that it yields operation history. However, it does not explicitly differentiate this from the sibling VPS_getActionDetailsV1, relying on implication via 'history' rather than naming the alternative.

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 gives a clear usage context: 'Use this endpoint to view VPS operation history and troubleshoot issues.' It does not mention when not to use it or compare it to alternatives such as VPS_getActionDetailsV1, so it stops short of a 5.

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