Get the status of a prepared eToro action

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond that: the meaning of each status, that approval is user-driven, and that history from earlier sessions is reachable. It does not describe return shape or latency, which is acceptable given no output schema but why it is not a 5.

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 core purpose and the full status enumeration are front-loaded in the first sentence, with the secondary history note after it. Two sentences, no filler, no repetition of the title.

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?

With a single required parameter, rich annotations, and no output schema, the description covers what the agent needs: what the states mean and the approval-driven lifecycle. It stops short of explaining behavior for an unknown/expired actionId or how the local-history lookup applies to cross-session IDs.

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 coverage is 0% (actionId has no description), but the schema does supply the UUID format and pattern. The description compensates by explaining where the actionId originates — from an action prepared by an etoro_prepare_* tool — which is the key missing semantic. It doesn't discuss expiry or lookup failures for unknown IDs.

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?

States a specific verb and resource (get the status of a prepared eToro action) and enumerates the possible states, so an agent knows exactly what comes back. It does not explicitly differentiate itself from the sibling etoro_get_action_history, and the closing note about finding actions 'from earlier sessions in the local history' slightly blurs that boundary.

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 phrase 'an action prepared by an etoro_prepare_* tool' clearly signals the workflow context: call this after a prepare tool to poll the result. It also states the important constraint that 'only the user can execute an action,' so the agent knows this is a passive status check. No explicit alternative (e.g. get_action_history for browsing) is named, 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.