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

The description reveals that the tool returns status, CNAME, and business type, which gives useful behavioral context about the output. However, since no annotations are provided, the description carries the full burden of disclosing behavioral traits like pagination, permissions, or whether it is a read-only operation. It does not address these, so it only partially fulfills the requirement.

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, front-loaded sentence with no filler. It states the action and resource first, then lists the key expected output fields. Every word contributes meaning.

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 zero-parameter list operation with no output schema, the description covers the core purpose and key return fields. It is not exhaustive about potential pagination or output format details, but given the simplicity of the tool, the provided description is largely adequate.

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, so the schema imposes no burden. The description correctly implies that no inputs are needed. Baseline for zero-parameter tools is 4, which is appropriate here.

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 clear verb ('列出' / list) and a specific resource ('腾讯云 CDN 加速域名'), and it explicitly names the key output fields (status, CNAME, business type). This distinguishes it from sibling tools like dns_list_domains or cloud_list_instances without 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?

The description provides clear context by specifying that this tool targets CDN acceleration domains, which naturally sets it apart from DNS domain listing and cloud instance listing. However, it does not explicitly state when to use this tool over alternatives, but the resource naming makes the intended scenario evident.

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?

No annotations are provided, so the description carries the full behavioral disclosure burden. It does state the mutating behavior and a validation constraint, but it does not disclose that the operation is likely asynchronous, that it invalidates/purges cached content, or that it may have quotas/costs. The '预热' (preheat) wording is also inconsistent with the schema's type enum, which only describes refresh 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?

The description is a single well-structured sentence with the core action front-loaded and conditionals following. Every clause contributes useful information, and there is no filler or redundant explanation. It is appropriately sized for a two-parameter tool.

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 correct input construction, the description is mostly complete: required parameters, type semantics, and path validation are covered. However, since there is no output schema, the description should at least hint at the return behavior (e.g., task ID) and note that progress can be checked via cdn_task_status. These gaps leave the agent without full end-to-end context.

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 parameter semantics baseline is 3. The description largely repeats what the schema already says about type and urls, adding no new meaning beyond restating the trailing-slash rule already present in the schema. It neither harms nor significantly improves parameter understanding.

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 resource (Tencent Cloud CDN cache) and the action (refresh or preheat), and it breaks down behavior by type=url vs type=path. It does not explicitly contrast itself with sibling tools like cdn_task_status, but the action is distinct enough to be understood. The mention of '预热' (preheat) is not reflected in the enum, which prevents a perfect score.

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 conditional guidance on when to use type=url vs type=path, including the trailing-slash validation rule for paths. This is clear context for invoking the tool. However, it does not mention the natural alternative/follow-up cdn_task_status for checking the refresh task result, so exclusion guidance is missing.

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?

No annotations are provided, so the description must carry the behavioral burden. It discloses the possible return statuses (fail/done/process) and the two query modes, which is useful. However, it does not describe the output shape, behavior for unknown task IDs, or ordering/limiting behavior beyond the schema default.

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 front-loads the action, status vocabulary, and both invocation modes. Every phrase adds useful information, with 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 status-query tool with two optional parameters and no output schema, the description adequately covers the core invocation choices and return status semantics. Combined with the fully documented input schema and the related cdn_refresh sibling, the agent has enough context to select and invoke the tool 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?

The input schema already describes both parameters completely, including the default for limit and the taskId behavior when left blank (100% schema coverage). The description does not add additional parameter meaning beyond what the schema states, 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 verb and resource: querying the status of Tencent Cloud CDN refresh tasks, and enumerates the possible status values (fail/done/process). This clearly identifies the action and distinguishes it from related tools like cdn_refresh, which creates tasks. It does not explicitly name an alternative, but the purpose is 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 gives clear usage context: query by task ID or query recent records. The schema further clarifies that taskId comes from cdn_refresh and that leaving it blank returns recent records. It does not explicitly state when not to use this tool, but no sibling offers equivalent status-checking functionality, so the guidance is sufficient.

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?

With no annotations, the description carries the behavioral disclosure burden. It reveals the key auto-detection behavior for Aliyun (ECS/SWAS) and Tencent (CVM/Lighthouse), which is valuable. However, it does not state that the operation is read-only, what happens on invalid IDs, or any response characteristics, leaving gaps.

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, efficient sentence that front-loads the primary purpose and then provides the provider-specific nuance. Every word earns its place, with no 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 tool, the description is reasonably complete, but the lack of an output schema means the agent cannot know what 'detailed information' will contain. Additionally, no error or permission context is provided, and with no annotations, the description could do more to round out the picture.

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 provides 100% coverage with descriptions and an enum for provider, so the baseline is 3. The tool description adds minimal direct parameter detail, though the auto-detection hint implies the instanceId can be any supported type. This is sufficient but not compensatory.

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 verb ('获取') and resource ('指定云实例的详细信息'), and adds the cross-provider auto-detection nuance, which distinguishes it from sibling listing tools like cloud_list_instances. It 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 implies usage context: given a specific instance ID and provider, it retrieves details and auto-detects the instance type. However, it does not explicitly state when to use this tool over alternatives like server_info or cloud_list_instances, nor any exclusions or conditions.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal one useful behavioral trait: SWAS automatically scans multiple regions, implying a broader and potentially slower search. However, it fails to state whether the operation is read-only, whether authentication is required, or how results are handled if no instances are 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 two sentences long with zero redundancy. It front-loads the core action (listing instances) and immediately enumerates the supported cloud providers and instance types. The final clause about SWAS region scanning adds important detail without bloating the text. This is an efficiently structured description.

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 tool has no output schema and no annotations, and the description does not indicate what data is returned for each instance, whether pagination is applied, or what error handling looks like. Given the tool's simplicity (one optional parameter), this is a moderate gap. The description does confirm the scope of the listing, so it is not entirely incomplete.

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 already provides full coverage for the single parameter ('provider'), including an enum and description. The tool description repeats the provider names but adds no new semantic information about parameter behavior, such as the effect of choosing 'all' or the format of the provider value. This meets the baseline expected when schema coverage is 100%.

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 explicitly states it lists Alibaba Cloud instances (ECS + SWAS) and/or Tencent Cloud instances (CVM + Lighthouse), using a specific verb and enumerating exact resource types. It also notes that SWAS automatically scans multiple regions, which further specifies the tool's scope. This provides a clear, unambiguous purpose that distinguishes it from generic server listing 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 gives no explicit guidance on when to use this tool versus alternatives like server_list or cloud_instance_info. It does not mention any exclusions, conditions, or alternatives, leaving the agent to infer usage solely from the tool's name. This is a notable gap given the many sibling tools present.

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?

With no annotations, the description carries the behavioral burden. It clearly signals a non-mutating inspection via '检查/校验/自检' and discloses exactly what is evaluated (ACL and policy for anonymous read). It does not mention required credentials or explicit 'no modification' wording, but the read-only intent is strongly evident.

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?

One dense, front-loaded sentence with no filler: it states the action, the exact check scope, and the intended use case. Every clause contributes.

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 is complete for a simple two-parameter check: purpose, scope, and use case are covered. There is no output schema, so return-value shape is left implicit, but '是否...开放读' strongly implies a boolean/verdict result, which is acceptable.

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 both parameters ('bucket', 'region') have adequate descriptions. The tool description adds no parameter-specific detail beyond the schema, so the 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 identifies a precise action—'综合检查' a COS bucket for anonymous read access—and explicitly scopes it to both bucket ACL and bucket policy. This clearly distinguishes it from sibling tools like cos_get_bucket_acl and cos_get_bucket_policy, which inspect only one source.

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?

States a concrete usage context: pre-launch security self-check to confirm private sensitive objects will not leak. It does not explicitly name when to prefer the individual ACL/policy sibling tools, but the '同时校验' phrasing implies those are for single-source checks, so the guidance is clear enough.

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?

No annotations are provided, so the description carries the burden. It clearly indicates a read operation ('获取') and describes what information is returned, but it does not disclose potential error conditions, permission requirements, or whether the ACL data is always present. Basic behavioral context is present, but depth is limited.

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 with no filler. The core function is stated first, the output contents are listed, and the intended use case is appended. Every sentence 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 2-parameter read-only tool with no output schema, the description gives enough context: what is returned and why it would be used. It does not describe response formatting, but that is not essential here. A dedicated alternative for public-read checks exists but is not mentioned, slightly reducing completeness.

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 parameters (bucket and region) with examples and defaults. The description adds no additional parameter semantics beyond what the schema provides, 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 verb and resource: fetching a Tencent Cloud COS bucket's ACL, including ACL level and grants (read/write/ACP/full control). This is clear and distinct enough from tool names like cos_get_bucket_policy, though it does not explicitly name or contrast 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 provides a concrete use case: confirming whether the bucket allows anonymous read access. However, it does not say when not to use this tool or mention dedicated siblings like cos_check_public_read or cos_get_bucket_policy, leaving the agent to infer routing correctly.

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?

With no annotations, the description carries the burden of conveying behavior. '获取' and '用于检查' clearly indicate a read-only operation, but the description does not disclose permission requirements, error conditions, or behavior when no bucket policy exists. This is acceptable for a simple getter but not rich.

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 operation is stated first, and the use case follows immediately, making it easy to scan and process.

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 read-only tool with full schema coverage, the description covers the main purpose and a common use case. It is complete enough for selection and invocation, though it leaves return-value details and edge cases unspecified.

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 the bucket name and optional region with a default behavior. The description adds no additional parameter-level detail, so it meets the baseline but does not exceed it.

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 identifies the exact resource ('存储桶的桶策略'), and adds the practical purpose of checking for anonymous read grants. It is clear, but it does not explicitly differentiate from the sibling cos_check_public_read, which may overlap in intent.

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 second sentence gives a concrete use case: verifying whether any policy grants anonymous principals read access. This provides context for when to call the tool, though it does not state when to prefer alternatives such as cos_check_public_read or cos_get_bucket_acl.

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?

With no annotations provided, the description carries the behavioral disclosure burden. It discloses that this is an overwriting PUT operation that replaces the bucket ACL, and explains the security rationale. It could further warn about the impact on intentionally public content, but the core mutating behavior and result are clear.

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 sentences with no filler. The first sentence states the exact operation and mechanism; the second gives the practical use case. It is front-loaded and every clause contributes.

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 tool is simple, parameters are fully schema-documented, and the description explains both the action and the security context. It does not describe the response or post-verification steps, but for a straightforward ACL-setting operation the description is sufficiently complete 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?

Schema description coverage is 100%, so both parameters are already documented in the schema. The description adds no additional parameter-level detail, which is acceptable given the schema fully handles parameter semantics. Baseline 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 uses a specific verb and resource: it explicitly sets the COS bucket ACL to private read/write via an overwrite PUT with ACL='private'. It clearly distinguishes itself from the read-only siblings like cos_get_bucket_acl and cos_check_public_read by stating the mutating action and target state.

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 usage context: it is meant to remediate the security risk where public-read access allows anonymous access to sensitive objects. It does not explicitly state when not to use it or mention alternative/complementary tools, but the intended scenario 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 word 'list' implies a read-only operation, which is useful context given that no annotations are provided. However, the description does not explicitly state that no data is modified, what the return value looks like, or whether special connection permissions are required. It is adequate but not richly transparent.

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 clear sentence with no filler or redundant content. It conveys the essential operation efficiently, which is ideal for a simple listing tool.

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 tool with one well-documented parameter and no output schema, the description is mostly sufficient. It clarifies the scope ('all databases') and the server type ('MySQL'). It could have added explicit return-format details, but the operation is straightforward.

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 compensate. The tool description itself does not elaborate on the 'database' parameter, but the input schema already explains that it refers to the connection configuration. This meets the baseline for high coverage.

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 verb (list) and the resource (all databases on the MySQL server), so an agent can quickly understand the tool's core function. However, it does not explicitly differentiate from sibling tools like db_list_tables or db_query, though the resource scope is clear.

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 tool is for enumerating databases on a MySQL server, but it provides no explicit guidance on when to use it instead of db_query, db_list_tables, or other listing tools. No exclusions or alternative selection criteria are given.

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?

With no annotations, the description carries the behavioral disclosure burden. It usefully discloses that row counts are estimates rather than exact values, which is meaningful for an agent. However, it does not explicitly state read-only behavior, permission requirements, or response shape.

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 that is front-loaded with the action and target, with no filler or repetition. It is appropriately concise for a simple listing tool.

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 low-complexity listing tool with fully documented parameters and no output schema, the description conveys the essential return content: tables and row-count estimates. It could be slightly more explicit about the database config name versus actual database name distinction, but the schema already covers that.

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%, with both database and dbName already documented clearly. The description adds no parameter-level detail beyond the generic phrase 'specified database', 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 verb ('列出' / list) and a precise resource: all tables in a specified database, including their row-count estimates. This clearly distinguishes it from siblings like db_list_databases (databases vs. tables) and db_query (querying vs. listing).

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?

There is no guidance about when to use this tool versus alternatives such as db_query or db_list_databases, and no exclusions or prerequisites are mentioned. The intended usage is only implied by the tool name and general wording.

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?

No annotations are provided, so the description carries the full burden. It does disclose that the tool can perform writes and deletes (INSERT/UPDATE/DELETE) and hints at large result sets via the LIMIT recommendation. However, it omits important behavioral context such as whether mutations are immediately committed, whether confirmation is required, or what the response looks like.

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 brief, front-loaded with the core purpose, and contains no filler. The LIMIT recommendation is useful but slightly redundant with the schema description, so it does not earn a 5.

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 3-parameter tool with fully documented schema properties, this description is mostly adequate. Missing context includes the return format for writes, error behavior, and how this tool relates to the specialized database listing siblings.

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 all three parameters. The description adds no new parameter-level semantics; the LIMIT advice is also present in the query parameter description.

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 it executes SQL queries on a specified database, listing the supported statement types (SELECT/INSERT/UPDATE/DELETE). It implicitly differentiates from sibling list-only tools like db_list_databases and db_list_tables, though it does not explicitly name them.

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 only usage guidance is recommending LIMIT for read-only queries. There is no explicit direction on when to choose this generic SQL tool over specialized siblings, nor any when-not-to-use guidance for potentially destructive operations.

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 reveals meaningful behavior beyond the name: git pull, npm install, build, PM2/Docker restart, and custom script execution. With no annotations, it still does not disclose side effects, prerequisites such as credentials, or the risk of restarting/overwriting remote services, so it only partially carries the transparency 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?

A single front-loaded sentence conveys purpose and key capabilities with no filler or repetition. It is compact but informative.

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?

Despite 9 parameters and 4 distinct methods, the description does not explain orchestration (e.g., how build/restart interact with each method, whether upload requires a source path, or what the tool returns). No output schema is provided, so an agent would struggle to predict response format or side effects.

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 prose adds no parameter-level meaning beyond summarizing methods already documented in the enum description (git-pull, upload, docker, script).

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 object: '将项目部署到远程服务器' (deploy a project to a remote server), then enumerates supported deployment methods. This clearly differentiates it from siblings like deploy_status (status checking) and server_exec (generic command execution).

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 the deployment tool for projects. However, it does not explicitly state when to prefer it over server_exec or how to choose among the four methods in terms of use cases, leaving the agent to infer routing from the method names.

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?

With no annotations, the description carries the behavioral burden. It signals a read-only action via the word '查看' (view) and names the status areas observed. However, it does not disclose requirements like SSH access, potential side effects, or the response format, leaving gaps beyond what is stated.

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 concise sentence that front-loads the core purpose and immediately provides specific examples of what is checked. There is no redundant wording 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 tool with only two simple parameters and no nested objects, the description is largely complete: it states the operation, the target (remote server/project), and the kinds of status supplied. The only missing piece is an explicit return format, but the informational content is sufficient 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?

The input schema fully describes both parameters (server name and project path) with 100% coverage, so the baseline is 3. The description adds no additional parameter-level meaning, but it also does not need to given the schema's completeness.

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 function—viewing deployment status on a remote server—and enumerates concrete items inspected (Git status, PM2/Docker processes, port listening). This specific verb-plus-resource phrasing distinguishes it from related siblings like deploy_project or server_exec.

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 clear usage context: inspect deployment state for a project on a given server. It does not explicitly list alternatives or when-not-to-use, but the scope is unambiguous enough that an agent can select it appropriately without confusion.

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?

No annotations are provided, so the description bears the full burden of behavioral disclosure. It only states that a record is created, but does not mention idempotency, duplicate handling, propagation time, whether existing records are affected, or authorization requirements. For a mutating tool this is a significant gap.

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, focused sentence that front-loads the core action and resource. Every word earns its place and there is no redundant scaffolding.

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 schema fully documents all five parameters, and the purpose is clear. However, the tool is a mutation with no annotations and no output schema, so an agent is left without guidance on expected return values, failure modes, or side effects. It is minimally sufficient but not 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 each parameter is already documented. The description adds only the record-type examples, which largely overlap with the schema's own examples. It does not add meaningful semantics 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 states a specific verb ('创建') and resource ('为指定域名创建一条解析记录'), and gives concrete record types (A/CNAME/TXT/MX). This makes it clearly distinct from sibling tools like dns_delete_record, dns_list_records, and dns_list_domains.

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 word '创建' implies the tool is for adding a DNS record, and siblings like dns_delete_record and dns_list_records provide contrast. However, the description does not explicitly state when to use this tool versus alternatives, nor mention any prerequisites or restrictions.

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?

With no annotations, the description itself must convey the behavioral profile; the word 删除 makes the destructive nature clear and the schema provides exact parameters. It does not mention irreversibility or error behavior when the record ID is invalid, so it is adequate but not richly transparent.

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 compact sentence leads with the action, then specifies the scope and provides the ID lookup pointer. Every element contributes value with no redundant text.

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 delete tool with fully documented schema and a clear record-ID acquisition path, the description is nearly complete. The main missing context is failure behavior and explicit irreversibility, which would matter more with additional 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?

The input schema already documents both parameters fully (100% coverage), so the baseline is 3. The description reinforces that recordId comes from dns_list_records but adds no new parameter semantics 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 uses a specific verb (删除) and resource (解析记录), scoping the action to a single record under a specified domain by record ID. This clearly differentiates it from dns_create_record and dns_list_records.

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 concrete usage context: delete by recordId under a domain, and explicitly points to dns_list_records as the way to obtain the record ID. It does not enumerate when-not-to-use cases, but the operation is unambiguous enough.

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?

With no annotations, the description must carry the full burden of behavioral disclosure. It clearly implies a read-only operation via the verb 'list' and specifies the output includes record counts, but it does not explicitly state whether any authentication is required, whether results are paginated, or any potential side effects. For a simple read tool, the implicit read-only nature is a reasonable baseline, but richer disclosure about output size or rate limits would be better.

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, well-structured sentence that front-loads the action and resource. Every word earns its place, and there is no redundancy or filler. It conveys both the scope (all domains) and an additional detail (record count) efficiently.

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 zero-parameter list tool with no annotations and no output schema, the description is entirely sufficient. It tells the agent exactly what the tool does and what to expect in the return (domains plus their record counts). There is no missing information required to invoke it correctly, and the simplicity of the tool lowers the burden on the description.

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, so the baseline is 4. The description does not need to elaborate on parameter meanings, and it does not attempt to. The mention of record counts is output-related rather than parameter-related, which is outside this dimension. No gaps exist since there are no inputs to document.

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 ('列出' = list) and a precise resource ('腾讯云 DNSPod 中托管的所有域名' = all domains hosted in Tencent Cloud DNSPod). It adds a distinguishing detail—each domain's record count—which separates it from siblings like dns_list_records and cdn_list_domains without needing to open schemas.

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 no guidance on when to use this tool versus alternatives. It does not mention dns_list_records for records or cdn_list_domains for CDN domains, nor does it state any conditions or exclusions. Usage must be inferred purely from the resource name.

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?

No annotations are provided, so the description carries the full behavioral burden. It discloses that this is a read/list operation and what fields the result includes, which is helpful. However, it does not mention authentication needs, error behavior for invalid domains, pagination, or whether the list is complete/untruncated.

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, information-dense sentence that leads with the core action and domain scope, then lists the returned fields. Every part earns its place with 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 single-parameter list operation, the description is nearly complete: it states the input, the result scope, and the returned fields. It is slightly lacking in usage caveats and behavioral details, but nothing critical 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?

The schema already provides full coverage for the single parameter with an example ('example.com'). The description adds no additional semantic detail about the domain parameter beyond what the schema states, so it sits at the baseline.

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 ('所有解析记录') scoped to a domain, and enumerates the returned fields (record ID, subdomain, type, value, TTL, status). This clearly distinguishes it from sibling tools like dns_list_domains, dns_create_record, and dns_delete_record.

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 use is implied: when you need all DNS records for a given domain. However, it does not explicitly state when to prefer this tool over dns_list_domains, nor does it mention that creation/deletion are handled by separate tools. No exclusion or alternative-condition guidance is provided.

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?

No annotations are provided, so the description carries the full burden. It correctly signals a read-only listing operation, but does not disclose additional behaviors such as whether the listing is recursive, includes hidden files, or what exact format the output takes.

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 concise sentence that clearly communicates the tool's function without any unnecessary words or filler. It is well-structured and easy to parse.

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 tool, the description conveys the core functionality. However, with no output schema and no annotations, it would benefit from clarifying what the returned list contains (e.g., names, full paths, file types) and whether any special permissions are needed.

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 two parameters (path and server) are already fully documented in the schema. The description itself adds no parameter-specific semantics beyond what the schema provides.

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 ('list') with a clear resource ('files and subdirectories in a specified directory on the remote server'). It clearly distinguishes file_list from sibling tools like file_read, file_write, and server_exec.

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?

Usage context is implied by the description — an agent can infer to use this tool when directory contents are needed. However, there is no explicit guidance about when to choose it over alternatives like file_search or server_exec, nor any exclusion scenarios.

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，描述承担全部行为披露责任。除'支持文本文件'外，未说明二进制文件处理、文件编码、大小限制、输出格式或权限要求；'读取'虽暗示只读，但未显式声明副作用或边界行为。

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?

描述仅两句话，首句直接点明核心功能，第二句补充支持的文件类型，没有冗余内容。信息密度高且结构清晰。

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?

工具没有 output schema 且没有 annotations，仅有简短描述，缺少返回内容、失败条件、权限要求等上下文。sibling tools 中的 file_write、file_search 等需要说明边界，当前描述不足以让 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?

input schema 覆盖了全部 3 个参数（server、path、tail）且每个都有描述，覆盖率 100%。描述没有在 schema 之外增加参数含义，'支持文本文件'与 tail 的日志场景略有关联，但未提供额外参数语义。

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?

描述明确说明'读取远程服务器上的文件内容'，动词和资源清晰，并补充了支持文本文件类型。虽然未显式区分 file_list、file_search、file_write 等 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?

描述没有说明何时使用 file_read 而非 file_search、file_list 或 server_exec，也未提及 tail 参数的使用场景（虽然 schema 中有）。仅通过'读取文件'暗示用途，缺少工具选择相关的指导。

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?

With no annotations, the description carries the burden and does convey that the operation is a remote, content-based grep-like search, which implies read-only behavior. It does not mention permission prerequisites, potential performance cost on large paths, or how results are truncated, leaving some operational behavior undisclosed.

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?

One compact sentence contains the core action, the tool's nature (grep), and typical use cases with no redundant wording. It is appropriately 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 moderately parameterized tool with full schema coverage and no output schema, the description provides enough context for invocation and gives concrete use cases. It does not describe the exact result format, but the grep analogy and schema parameters (context, maxResults) make the expected output reasonably 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 input schema already documents all 6 parameters with descriptions, so the baseline is 3. The description adds the grep analogy and use cases but no per-parameter details beyond what the schema provides.

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 concrete operation—searching file contents on a remote server via grep—and adds concrete use cases (finding errors in logs, config items). This clearly separates it from sibling file tools like file_read and file_list by emphasizing content search rather than reading or listing.

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 explicit scenarios where the tool is appropriate: searching logs for errors and locating config items. It does not enumerate exclusions or compare directly with file_read/file_list/server_exec, so it stops short of full routing guidance.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It explicitly discloses the destructive overwrite behavior ('会覆盖已有文件'), which is the most important safety concern. It does not mention permissions, file creation, or error cases, but the overwrite warning adds significant value.

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 concise sentence that front-loads the action and includes the key side-effect warning in parentheses. There is no wasted wording, and the overwrite caution is prominently placed.

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 purpose and the critical overwrite side-effect, which an agent needs to know before invoking the tool. It lacks details about return values or error conditions, but for a straightforward file-write operation, it is reasonably complete given the moderate 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?

The input schema covers all three parameters (server, path, content) with descriptions at 100% coverage, so the schema already explains what each parameter means. The description repeats the concept of content and remote server but adds no additional semantic detail beyond the schema's baseline.

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 ('write') and resource ('remote server file'), and explicitly notes the overwriting behavior. This clearly distinguishes it from sibling read concerns like file_read, file_list, and file_search, so an agent can identify it as the write operation.

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 use when you need to write content to a remote file, but provides no explicit exclusions or alternatives. It does not compare with server_exec, which could also modify files, leaving the when-not-to-use guidance implicit 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?

No annotations are provided, so the description carries the burden. It explicitly discloses key side effects: persisting to .env and updating the in-memory cache, plus the operational benefit of no restart required. While it does not detail error cases or security implications, the main behavioral traits are transparently stated.

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, dense sentence that front-loads the main action ('register a new SSH server') and immediately states the important side effects. Every word earns its place, with no redundancy or tangential 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?

The tool has 6 parameters, no output schema, and no annotations. The description covers the core purpose and side effects, but omits guidance on conflict resolution (e.g., duplicate name) or success feedback. While the schema handles parameter details, the lack of outcome/error behavior means the description is adequate but not fully comprehensive.

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 tool description does not add parameter-specific meaning beyond what the schema already conveys (e.g., host, username, port, password vs privateKey). The description's focus is on the operation, not the parameters, so it neither compensates nor degrades beyond baseline.

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 specific action ('register a new SSH server at runtime') and the resource (SSH server), plus mentions the side effects (write .env, update cache). It distinguishes itself from siblings like server_list and server_exec by focusing on the addition operation.

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 use case: add a server without restarting the connector, making it available to server_exec. However, it does not explicitly contrast with alternatives (e.g., manually editing .env) or provide when-not-to-use conditions. The context is clear but not fully elaborated.

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 return format (stdout, stderr, exit code), which is helpful. However, with no annotations to rely on, it fails to mention important behavioral traits such as the potentially destructive or irreversible effects of executing commands on a remote server. There is no caution about side effects, permissions, or error-condition behavior, which is a significant gap for a remote execution tool.

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, front-loaded sentence that clearly states the action and the return values. There is no wasteful text, and the most important information (what the tool does) appears 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?

The description covers the basics: what it does and what it returns. However, it omits critical safety context about the risks of executing arbitrary remote commands, such as potential server modifications or irreversibility. For a tool that can run arbitrary shell commands, this is a notable gap. The schema provides parameter details, but the description does not give enough behavioral context for safe and 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?

All four parameters are fully described in the schema, so the baseline is 3. The description itself does not add any parameter-specific meaning beyond a vague reference to 'specified remote server' and 'Shell command', which the schema already captures.

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 ('execute') and a clear resource ('Shell commands on a specified remote server'), and explicitly lists the return values (stdout, stderr, exit code). This clearly distinguishes it from sibling file, deploy, and database tools, so an agent can identify its purpose without confusion.

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 tool is for running arbitrary shell commands, but it does not provide explicit guidance on when to use this tool versus alternatives like deploy_project or file_read. There are no exclusion criteria or mentions of alternative tools, leaving the agent to infer the appropriate context from the tool's name and short description.

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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It indicates a retrieval-style operation and names the output categories, which is useful, but it does not explicitly confirm non-mutating behavior, authorization requirements, failure modes, or how the information is returned. Some transparency is present, but not full.

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 front-loads the action and resource, then lists the information categories with no filler. Every word contributes meaning.

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 info tool with no output schema, the description covers the essential call contract: which server to pass and what output categories to expect. It does not describe formatting, units, or error behavior, but given the low complexity, the description is substantially 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% because the only parameter, 'server', is already described as '目标服务器名称' (target server name). The description adds no additional parameter semantics, such as accepted formats, constraints, or how to discover valid server names, 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 uses a specific verb ('获取', get) and a specific resource ('远程服务器的系统信息', remote server system information), then enumerates the exact categories returned: OS, CPU, memory, and disk usage. This is clearly a read-only server details tool and is readily distinguishable from siblings like server_list and server_exec.

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 tool should be used when system-level information about a target server is needed, but it does not explicitly state when to prefer this over related tools such as server_list or cloud_instance_info. It also does not mention prerequisites, such as obtaining a valid server name from server_list, or provide any when-not-to-use guidance.

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?

没有任何注解，因此描述承担行为说明责任。动词“列出”隐含只读操作，且“可连接的”增加了筛选条件，但描述未说明返回格式、是否会真的检测连接可用性、是否需要权限，以及是否可能因网络检查而变慢。对于简单列表工具已提供基本行为，但还不够充分。

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?

描述是一句完整且无冗余的中文单句，核心信息动作和对象都在句首，没有任何浪费篇幅的内容，清晰易读。

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?

工具本身较简单且无参数，描述给出了列取范围和连接性条件，但缺少使用场景指引、输出形态说明以及与其他服务器相关工具的区分。对于代理选择工具而言，基本可用但仍有明确缺口。

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?

工具没有参数，输入模式为空，因此不存在参数语义负担。按基线规则，0 参数工具应给予 4 分，描述无需补充参数说明。

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?

描述明确使用动词“列出”并明确指出对象是“当前 MCP 配置中所有可连接的服务器”，资源范围和动作都很清晰。与同组的 server_info（单服务器信息）相比，通过“所有”明确了枚举型操作，能够有效区分用途。

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?

描述只说明工具能做什么，没有说明何时应该使用它、何时不应该使用它，也没有提及替代工具如 server_info 或 server_exec 的选择条件。调用场景完全依赖名称和用户推断，缺乏显式指引。

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