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?

Beyond the annotations, the description discloses the key financial consequence: it deducts one month's package cost from the balance and spends real money. It also mandates user confirmation before invocation, which is critical behavioral context not present in the structured 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 focused sentences: the first states purpose and billing effect, the second states the mandatory consent step. There is no filler, and the critical warning 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 two-parameter creation tool with no output schema, the description covers the essential purpose, cost, and user-consent requirement. It does not describe what is returned after creation or suggest a follow-up tool like list_vps, leaving a small completeness gap.

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 description does not need to explain the parameters. It adds no meaning beyond the schema, which already documents the name pattern and tier options with prices, so a 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 a specific action and resource: 'Tạo một server mới' (create a new server), which clearly distinguishes it from sibling tools like list_vps, destroy_vps, or deploy_app. It also adds the billing side-effect, making the function's purpose unmistakable.

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: confirm the price with the user and obtain consent BEFORE calling the tool, because it spends real money. It does not mention alternative tools or when not to use it, so it stops short of a full 5.

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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context: it returns the most recent log and only makes sense in error scenarios. It does not describe output format or pagination, but the annotation coverage lowers the burden.

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 with no filler. The core purpose and trigger condition are front-loaded, and the practical prerequisite about app_id is stated directly afterward.

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 main use case and the app_id source, but it does not mention where vps_id should come from or what the returned log contains. Since there is no output schema, a little more detail about the return value would improve completeness. Overall it is adequate for a simple read-only log tool but has a clear gap around vps_id.

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 both app_id and vps_id with formats. The description reinforces that app_id comes from list_apps, which matches the schema, but it adds no meaning beyond what the schema already provides. 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 log gần nhất') on a specific resource (app logs) and gives a concrete trigger condition ('khi app ❌ lỗi'). It also points the agent to list_apps as the source for app_id, making the purpose unambiguous even among sibling 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?

The description tells the agent when to use this tool: when an app has errored and recent logs are needed. It also gives a clear prerequisite, retrieving app_id from list_apps, though it does not explicitly mention alternative tools or exclusions. Since no sibling tool competes for the same log-reading purpose, no exclusion is strictly necessary.

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?

Beyond the readOnlyHint annotation, the description discloses the exact behavior for both invocation modes: omitting the parameter returns a short list to ask the customer, while passing phong_cach returns a full formula. It also clarifies this is reference data to write better code, not a customer-facing response. 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 short, front-loaded with the key instruction ('TRƯỚC khi viết giao diện'), and uses compact arrow notation to explain modes. Each sentence contributes essential information: purpose, behavior, and a usage caveat. There is no redundancy or filler.

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 lookup tool with one optional parameter and no output schema, the description provides enough information to call it correctly: what it returns in each mode, when to use it, and its role as reference data. No critical context is missing.

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 already explains that phong_cach is an ID confirmed with the customer and can be left blank to view the list. The tool description adds value by specifying the output difference: a short list vs. a full formula for the given style. This enriches understanding of the parameter's effect beyond the schema.

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 tool consults TocBien's presentation style library ('Tra thư viện kiểu trình bày') and is meant to be used before writing the interface. It distinguishes itself from the sibling action/deployment tools by emphasizing it provides reference data, not an action. The two modes (empty vs. provided parameter) further clarify its function.

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 explicitly states when to use it: 'TRƯỚC khi viết giao diện' (before writing the interface). It also provides a boundary: 'không thay lời khách' (not a substitute for the customer's words), clarifying when not to rely on it. This gives clear context without needing to name sibling alternatives.

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?

The description uses 'Xem' (view) and 'Đọc' (read), clearly indicating a read-only operation, which aligns with the readOnlyHint annotation. It also mentions checking status 'trước khi trừ tiền', suggesting no side effects on billing. No contradiction with the destructiveHint or openWorldHint annotations is present.

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 but somewhat cluttered with mixed-language jargon like 'kho thật' and 'instantReady', and the final clause about reading before deducting money feels slightly out of place. It conveys the main idea without excessive verbosity, but the structure could be cleaner.

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?

Given that there is no output schema, the description provides useful context about the contents (plans and terms) and hints at its role in a purchase flow. However, it does not explain what 'instantReady' means or what the returned data structure looks like, leaving some ambiguity for an agent.

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 schema describes none, so there is nothing for the description to clarify. The baseline for zero parameters is 4, and the description does not introduce any parameter-related ambiguity.

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 this is a price list viewer ('Xem bảng giá') and enumerates the specific plans (Mach 1-6) and durations (1/3/6/12 months), giving concrete detail about the resource. It distinguishes itself from sibling tools like list_vps or list_apps by focusing on plans/pricing, though the inclusion of 'kho thật' and 'instantReady' adds some jargon.

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 a usage context: 'Đọc instantReady trước khi trừ tiền' suggests checking availability before payment, but it does not explicitly state when to use this tool versus alternatives like list_vps or list_apps. No direct comparison or exclusion criteria are provided, so the guidance is more implicit 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 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.