Tốc Biến

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

Annotations already show the operation is not read-only and not destructive. The description adds useful behavioral details like 'miễn phí' and 'SSL tự động', but it does not disclose side effects such as DNS propagation, whether attaching is idempotent, or what happens on duplicate labels.

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 unnecessary filler. It front-loads the core action and includes the key benefits (free, automatic SSL) without redundancy.

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 simple two-parameter mutation tool with 100% schema coverage and no output schema, the description is mostly complete: it states the target VPS condition, the domain format, and value-add behavior. It leaves out return/error behavior, but that is a minor gap for such a straightforward operation.

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 the schema already explains both parameters. The description's reference to '<tên>.tocbien.app' reinforces the label pattern but does not add meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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 states a specific verb ('Gắn' / attach), a clear resource ('subdomain <tên>.tocbien.app'), and the target object ('một VPS đang chạy'). This clearly distinguishes it from the sibling tools, none of which handle subdomains.

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 clear context for when the tool applies: to a running VPS. It does not explicitly list alternatives or exclusions, but the sibling set contains no competing subdomain tool, so the intended use is reasonably clear.

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

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

Annotations already indicate this is a non-read-only, non-idempotent operation. The description adds the return behavior (VietQR code) and package details, but it does not disclose that the account is likely credited only after payment is completed, nor the side effects of creating multiple orders. No contradiction with annotations, but the behavioral picture is incomplete.

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 compact and front-loaded with the core purpose and output. The second sentence adds package-format and promotion details that help in choosing the plan parameter, though it is slightly more marketing-like than strictly necessary.

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?

There is no output schema, so the description needs to explain the return value; it does mention the VietQR code, but it omits details such as whether an order ID is returned and how to check order status afterward. For a tool with only one parameter, this is mostly adequate but leaves notable gaps around the payment flow.

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 100% and the enum values are already documented, so the baseline is 3. The description adds value by explaining the package format (<tier>-<duration>), the pricing tradeoff per month, and the extra .com domain bonus for certain 12-month plans, which helps the agent choose a correct plan value.

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 uses a specific verb and resource ('Nạp tiền vào tài khoản' – top-up the account) and clearly states the key output ('trả mã QR VietQR'). This makes it easy to distinguish from siblings like create_vps and get_order_status without naming them explicitly.

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 clear context for when to use the tool: when the goal is to recharge the account and receive a VietQR payment code. It does not explicitly mention exclusions or alternative tools, so it stops short of a 5, but the intended use is unambiguous.

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

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

The description explicitly discloses the financial side effect: it deducts one month's plan cost from the balance and spends real money. This goes well beyond the annotations, which only indicate non-read-only and non-idempotent behavior, and is critical for safe agent invocation.

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 two concise sentences, front-loading the core action and financial impact, then placing the mandatory user-confirmation warning. Every word earns its place and the warning is highly visible.

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 covers the essential side effect, cost amount, and required user confirmation, which are the key safety elements for this tool. It does not mention the return type or behavior on insufficient balance, but given only two well-documented parameters and existing annotations, the description is close to complete.

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%, including tier pricing and name pattern, so the description does not need to repeat parameter details. It adds a useful billing context ('1 month cost'), but no additional parameter-level semantics that are not already present.

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 'Tạo một server mới' and the resource being created, differentiating it from sibling tools like list_vps and destroy_vps. It also adds the key qualifier that creation deducts one month's cost, which sharpens the purpose beyond the title.

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 an explicit precondition: the agent must confirm the price with the user and get consent before calling the tool. It does not explicitly contrast with sibling alternatives, but the when-to-use context is clear and actionable.

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

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

Annotations already signal a non-read-only, non-idempotent, non-destructive action, and the description adds that each app gets a unique slug/subdomain and that multiple apps can run in parallel. It does not, however, disclose lifecycle details such as image pulling, port behavior, failure states, or whether the deployment result is asynchronous, so it only partially extends beyond the annotations.

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 two short sentences, front-loads the core action, and uses concrete examples without filler. Every clause contributes useful context about installation, public images, naming, and parallelism.

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 core operation and its high-level constraints are clear, and the schema covers all parameters. However, there is no output schema and the description does not say what a caller receives (e.g., status, order ID), how to choose vps_id, or whether the operation is asynchronous, which are meaningful gaps for a non-idempotent creation action.

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 vps_id, slug, image, and port are already documented in the schema. The description reinforces the public-image requirement and the slug-to-subdomain relationship, but does not add meaningful details beyond the schema, especially for vps_id and port. Baseline 3 is appropriate.

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 a specific action ('Cài app CÓ SẴN') and resource ('docker image công khai'), with examples (n8n, WordPress) and the slug/subdomain model. It distinguishes itself from deploy_code through 'CÓ SẴN', but it does not explicitly name or contrast that sibling, so it stops short of a 5.

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 'CÓ SẴN từ docker image công khai' implies when to use the tool: when deploying a ready-made public app image. However, it never states when not to use it or directs the agent to deploy_code/prepare_code_deploy for source-based deployments, so the routing guidance is implied rather than explicit.

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

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

Annotations only indicate non-read-only/non-destructive; the description adds meaningful context: it builds/runs, creates a single app per call, supports parallel apps, assigns HTTPS domains, and auto-detects stack. It does not disclose failure behavior or overwrite semantics, but it adds useful detail beyond annotations.

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 short and front-loaded with the main action, and each clause adds context (parallel apps, domain/HTTPS, auto-detection). It is dense but not wordy.

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 covers the core deploy workflow and key behaviors, and the schema handles parameter documentation. But with no output schema and minimal annotations, it does not describe expected return values or differentiate from deploy_app, leaving some gaps.

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% and already documents port, slug, vps_id, and upload_id. The description does not add meaningful parameter-specific explanation beyond restating that slug becomes the domain.

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?

Description clearly states the tool builds and runs uploaded source code into one app, with slug-based domain and automatic HTTPS. It identifies the verb+resource, but does not differentiate from the sibling deploy_app, leaving some ambiguity.

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?

"Bước 2" implies this is the deployment step after uploading source, and the schema ties upload_id to prepare_code_deploy. However, the description does not explicitly state when to use this versus deploy_app or provide exclusions.

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

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

Annotations already flag destructiveHint=true, but the description enriches this by specifying the non-refundable nature ('không hoàn tiền phần đã dùng') and irreversibility ('không đảo ngược được'). It also clarifies the confirmation requirement, adding real behavioral context beyond the structured hints. No contradiction with annotations.

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 one compact sentence with the primary action front-loaded, followed by two crucial warnings in parenthetical and dash clauses. Every element earns its place; no fluff.

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 2-parameter destructive tool with no output schema, the description covers the essential facts: what is destroyed, financial impact, irreversibility, and the confirmation flag. It could mention error handling for nonexistent VPS, but that is not required for correct invocation and the core behavioral context is complete.

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 the schema already documents vps_id and confirm. The description merely restates the confirm requirement ('Cần confirm=true') without adding new semantic meaning to either parameter. Baseline 3 is appropriate.

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 'Hủy một VPS', a specific verb and resource that clearly identifies the operation as destroying/canceling a VPS. It adds differentiating details (no refund, irreversible) that go beyond the title and set it apart from sibling tools like create_vps or list_vps.

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 clearly implies when to use the tool — when the agent intends to permanently destroy a VPS — and provides the required precondition 'Cần confirm=true'. However, it does not explicitly name alternatives or state when not to use it, so it falls short of the top score.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds that the response includes status and credit balance, which is useful, but it does not describe error behavior, status values, or authorization needs.

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?

A single well-formed sentence that states the operation and the returned information with no filler. The structure is appropriately minimal for the tool's simplicity.

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 one-parameter read-only tool with strong annotations and full schema coverage, the description is almost complete: it names the resource and the return values. It only lacks explicit guidance on when to use it relative to order creation.

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 the baseline is 3. The description does not add parameter-level detail beyond tying the order to a top-up ('đơn nạp tiền'), while the schema already documents the TBXXXXXXXX format.

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 uses a specific verb ('Kiểm tra' / check) and a clear resource: the status of a top-up order plus credit balance. This clearly distinguishes it from sibling create/deploy/destroy tools.

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?

No guidance is given about when to call this tool versus alternatives such as create_order or list tools. The use case is implied by the name but never explicit.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the output includes URL and deploy status, but does not reveal ordering, pagination, or error behavior.

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?

A single, well-structured sentence conveys scope, parenthetical clarifiation, and output fields without any waste. The key information is front-loaded.

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 simple read-only tool with one required parameter and no output schema, the description adequately states the returned information (URL, deploy status) and the per-server scope. Missing details like response format or edge cases are minor for this complexity.

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 100% for vps_id, so the schema already documents the parameter. The description connects the field to the server context ('trên một máy chủ'), but adds no detail beyond that.

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?

Description states a specific verb ('Liệt kê') and resource ('các app đang chạy trên một máy chủ'), clearly distinguishing it from sibling tools like list_vps (which lists servers) and list_plans. Also specifies key output elements (URL, deployment status).

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 implies the usage context: provide a vps_id to list apps on that machine, with 'nhiều app/máy' indicating one server can host multiple apps. However, it does not explicitly state when to choose this over alternatives such as list_vps.

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

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

Annotations already cover read-only and non-destructive behavior, so the description's added detail about the exact package names and term durations provides useful behavioral context. It accurately reflects the tool's output without contradicting the annotations. It does not mention return format, but for a simple read-only list this is not a significant omission.

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?

A single sentence that front-loads the primary purpose ('view price list') and then provides precise, complete structural details. There is no verbiage or redundancy, and every word earns its place.

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 read-only, zero-parameter, no-output-schema tool, the description is nearly complete. It fully describes the scope of the data being returned. The only minor gap is that it doesn't explicitly state these are VPS plans or mention currency/pricing format, but 'price list' and sibling context make that sufficiently clear.

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 tool accepts zero parameters, so the description does not need to explain parameter semantics. Per the rubric, a zero-parameter tool gets a baseline of 4. The description's structural detail about packages and terms is sufficient.

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 states a specific action ('Xem' = view) and a specific resource ('bảng giá TocBien' = price list), then enumerates the exact contents: 6 packages (Mach 1–6) each with 4 term lengths (1/3/6/12 months). This clearly differentiates it from sibling tools like list_vps (instance list) and list_templates (deployment templates).

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 intended usage is implied by the name and description: an agent would call this to retrieve pricing options before placing an order. However, there is no explicit when-to-use guidance, no mention of alternative tools, and no exclusions. The context is clear but not explicitly stated.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds that this returns a list of popular deploy-ready templates, but it does not mention what information is returned or whether the list is curated/static. No contradiction with annotations.

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?

Two short sentences front-load the main action and follow with the usage context. No filler or redundant restatement of the schema fields.

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 parameterless, read-only list tool, the description is sufficient: it states what is listed, the deployment context, and the advice use case. The lack of an output schema is a minor gap but not critical for this simple operation.

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 tool takes zero parameters and schema coverage is 100%, so there is little for the description to add. Baseline 4 applies for a parameterless tool.

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 names a concrete verb (list), a resource (popular templates that can be deployed immediately through TocBien), and an intended use case (advising users on solutions). It does not explicitly contrast itself with the sibling list_apps, but the qualifiers 'popular' and 'deploy immediately' give enough scope to avoid serious ambiguity.

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 when to use the tool: when advising users on templates/use cases that can be deployed right away. It does not give exclusions or explicitly name alternative tools, but the intended context is clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful context by specifying that the response includes VPS status and deploy status, but does not mention pagination, filtering, or other behavioral traits. This is acceptable for a simple list operation but not exceptional.

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, compact sentence that immediately states the action and the key output detail. Every word contributes value, and there is no redundant information.

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 no-parameter, read-only list tool, the description is complete. It explains what the tool returns (VPS list with status and deploy status), and the annotations cover the safety behavior. No output schema exists, but the description provides enough detail for correct invocation.

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 tool has zero parameters and the input schema is empty, so the baseline is 4. The description correctly implies that no input is needed beyond the implicit account context, which is sufficient.

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 states a specific verb ('Liệt kê' – list), the resource (VPS của bạn – your VPS), and the key output detail (status including deploy status). It clearly distinguishes this from sibling tools like list_apps and list_plans by naming the VPS resource directly.

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 context is clear: this is a read-only listing tool for VPS instances. However, it provides no explicit guidance on when to prefer it over similar sibling tools, such as list_apps, or when not to use it. Usage is implied rather than explicitly stated.

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

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

Annotations only mark readOnlyHint=false and destructiveHint=false; the description adds key behavioral context by revealing that the tool returns a shell command the agent must execute, that the command must be run at the project root, and that an upload_id is produced. It does not detail side effects of the command, but the core non-obvious behavior is disclosed.

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?

Two concise sentences front-load the purpose and then give precise execution guidance. The all-caps emphasis is purposeful in flagging exact execution as critical.

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 one-parameter tool with no output schema, the description covers the essential workflow: the returned value is a shell command, it must be executed at the project root, and the resulting upload_id feeds into deploy_code. The response field names are not specified, but the necessary next-step information is present.

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 100%: vps_id is documented as the server id from list_vps. The description adds no extra parameter detail, so the baseline score of 3 applies.

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 states a specific purpose: it is the first step to get the user's code onto the server and returns a shell command. This clearly identifies the tool's role and differentiates it from deploy_code, which is the follow-up step.

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 explicit operational instructions: run the returned shell command exactly at the project root and then call deploy_code with the upload_id. It names the sibling tool and the sequence, leaving no ambiguity about when and how to use it.

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