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 include destructiveHint=true and idempotentHint=true. The description adds context beyond annotations by clarifying that it does not affect running machines, and it explains idempotency in terms of using a separate key for the cancel intent and retaining it on retry. However, it does not elaborate on what happens to the underlying resource or whether there are any side effects, which is partially covered by annotations. No contradiction found.

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 concise, three sentences, with no filler. It front-loads the primary action and scope, then provides retry guidance. Every sentence adds value, and it is well-targeted for an agent.

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 2-parameter tool, the description is complete. It covers purpose, alternative scoping, idempotency, and parameter source. The absence of an output schema is acceptable since the tool is a cancel action. The only minor gap is it doesn't describe the response format, but that may not be necessary given the simplicity.

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 schema covers 50% of parameters with description, specifically the idempotency_key has a detailed description. The 'id' parameter only has a type and length constraints. The tool description says to get the id from get_trial, which adds context for the 'id' parameter. This compensates partially for the low coverage, but additional detail on the 'id' parameter would be useful.

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 ('cancel a pending request') and the resource ('trial request'). It explicitly distinguishes itself from a sibling by noting 'does not delete a running machine,' and references the sibling tool (get_trial) for obtaining the ID. This is specific and unambiguous.

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 provides clear context for when to use this tool: when the user wants to cancel a pending trial request. It also mentions using get_trial to obtain the ID, which implies a workflow. However, it does not explicitly state when NOT to use this tool (e.g., for deleting running machines) with alternative wording, though the current phrasing covers the exclusion indirectly.

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 discloses the key side effect: a real charge of one month's plan cost from the user's balance. It also adds important behavioral constraints: no automatic fallback to trial and required user confirmation before calling. This goes beyond the annotations, which only mark readOnlyHint as false.

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 every sentence carries meaningful operational guidance. It could be slightly improved by moving the critical confirmation warning closer to the front, but it is not bloated or redundant.

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 purpose, exclusions, payment side effects, and the mandatory user-consent precondition. It does not describe post-call behavior such as provisioning time or how to verify the created server via list_vps, but that is a minor gap for a paid-action tool.

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 input schema already fully documents both parameters: name has a pattern and example, and tier is an enum with per-tier pricing. The description adds no per-parameter detail beyond the schema, 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 clearly identifies the action: creating a new paid server and deducting one month's cost from the balance. It also distinguishes itself from trial-related tools by explicitly stating that get_trial/request_trial are separate and that trial upgrades happen only in the console.

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 when-not-to-use guidance: do not use it to automatically switch to a trial, do not use it to upgrade a trial server, and only call it after the user has approved the price. It even names the alternative tools (get_trial/request_trial).

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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is known. The description adds value by specifying exactly what is read (conditions and status) and by reinforcing that no machines are provisioned. It does not go into auth or rate limits, but for a read-only tool this is sufficient.

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 with no filler. It front-loads the primary action and resource, then adds a clarifying negation. 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 simple, zero-parameter, read-only tool with rich annotations, the description is largely complete. It explains what information is returned (conditions/status) and what it does not do. The absence of an output schema is slightly mitigated by the low complexity, though exact return formatting is not described.

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 is empty (100% coverage), so there are no parameter semantics to add. Baseline for 0 params is 4, and the description correctly focuses on the operation rather than parameters.

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 ('read'), resource ('conditions and trial status'), and scope ('connected account'), which clearly differentiates it from provisioning tools like create_vps and from request_trial/cancel_trial. The explicit 'does not provision machines' further disambiguates from write-like siblings.

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 usage for reading trial conditions/status but does not explicitly mention when to use it over request_trial or cancel_trial, nor does it state any exclusions beyond 'does not provision machines'. No direct guidance on choosing this tool among siblings.

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/destructiveHint annotations, it reveals call-ordering requirements, the empty-parameter behavior (list + default to ask the customer), the provided-parameter behavior (style formula), and that the data is reference-only and should not replace customer input. 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?

Four short, high-signal sentences with the most important instruction ('must call before UI') front-loaded. Every sentence carries operational value and there is no filler or repetition of schema data.

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 suggestion tool with one optional parameter and no output schema, the description covers when to call, what each mode returns, and how to treat the data. Nothing essential is missing for an agent to invoke it correctly.

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%, so the schema already documents phong_cach. The description adds behavioral meaning for omitting vs providing the value, reinforcing that the id comes from the list and that empty means 'show list'. This is useful added context, though the extra term 'camMacDinh' is slightly 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 clearly states the tool's role: a design/presentation-style suggestion that must be called before writing a UI. It distinguishes itself from sibling tools by tying invocation to interface work and explaining the two modes (empty list vs style formula).

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?

Explicitly tells the agent to call it before writing any UI and explains the consequence of skipping it ('page like every AI...'). It does not name alternative tools or explicit when-not-to-use conditions, but the timing and conditional parameter behavior are 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, 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.

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

The description adds meaningful behavioral context beyond the annotations: the trial is auto-approved via API, provisioning may involve waiting for a machine, and the call is not a billing or upgrade action. The retry guidance reinforces the idempotentHint annotation without contradicting any structured metadata.

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?

Every sentence carries a distinct operational fact: precondition, approval behavior, non-billing/non-upgrade, and timeout handling. The description is dense but compact and front-loads the most important invocation requirement first.

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 tool with three required parameters and no output schema, the description covers the preconditions, side effects, timeout procedure, and distinction from related tools. An agent has enough information to invoke it correctly and to recover from timeout by consulting get_trial.

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 description reinforces the semantics of idempotency_key by explicitly saying to reuse the same key and payload on retry, and links acceptTerms to the prerequisite of user consent. However, it adds little specific meaning for the name parameter beyond what the schema pattern already provides, so it is strong but not maximal.

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 clear action: request a trial only when the user has requested it and accepted the terms. It also distinguishes this from related operations by explicitly saying it does not charge and does not upgrade, setting it apart from billing and upgrade tools like create_order and cancel_trial.

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 gives an explicit precondition: the user must have agreed to the terms at a specific URL. It provides timeout handling by directing the caller to read get_trial and retry with the same key/payload, and clarifies that this tool is not for charging or upgrading.

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