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

With annotations already declaring readOnlyHint=false, idempotentHint=true and destructiveHint=false, the description goes well beyond them: asynchronous queueing, the RPScripts agent performing the download/check/unpack, the target path resources/[rpscripts]/<name>/, backup creation, owner confirmation before replacing an existing folder, refusal of server packs and non-ZIP files, and the fact it consumes a download quota. This is exactly the extra context annotations cannot carry.

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 action is front-loaded, and every clause carries information (provenance, defaults, side effects, refusals, next step) with no filler. It is dense, though the long parenthetical about list_purchases and list_servers makes the opening sentence a little heavy.

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 three-parameter mutation tool with no output schema, the definition covers inputs, async lifecycle, filesystem target, replacement confirmation flow, failure modes (server packs, non-ZIP), and how to verify the outcome. An agent has everything needed to invoke it and interpret the result.

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 0%, so the schema documents only types, UUID patterns and the 0-999 range for file_index. The description compensates by explaining that product_id identifies an owned product, that file_index selects one file of that product, and that server_id identifies a connected server and is optional when exactly one exists. It does not spell out what happens when file_index exceeds the product's file count, leaving the upper bound of 999 unexplained.

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 opens with a precise verb+resource+scope: 'Queues one file of a product the signed-in customer owns ... for installation on one of their connected FiveM servers.' It distinguishes itself from adjacent siblings (get_download_url, list_purchases, install-adjacent validation tools) by naming the file-level, server-targeted unit of work and where the identifiers come from.

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 the provenance of both key inputs (product_id/file_index from list_purchases, server_id from list_servers) and the exact condition under which server_id may be omitted. It also prescribes the follow-up ('Follow the result with list_servers'). It stops short of naming a concrete alternative operation (e.g. download-only via get_download_url) for users who do not want installation.

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